To put it briefly,
can we use polling to find whether UDP packets are being dropped at the
UDP socket buffer? If so how ?

09-30-2007, 10:36 AM

unix

Re: polling

Guddu wrote:[color=blue]
> To put it briefly,
> can we use polling to find whether UDP packets are being dropped at the
> UDP socket buffer? If so how ?[/color]

You have UDP all wrong, it is really only useful for talking to a lot
of clients at once. For example if you want to push the same file out
to 20 machines, in theory UDP is 20 times faster than with "normal"
TCP/IP communications. (Theory only because UDP drops packets like a
dog).

To make things work you need to find a way to let the receivers know
what they should be expecting, and than have a way for the receivers to
notify the sender that they missed a packet. So number and checksum
each packet, and send a 'header' packet with the total packet count.
Thain each client will keep track of what packets they received and
after a fixed interval they will begin re-requesting the missing
packets (requests can be done without UDP for reliability). Thain the
server queues up requests and after a fixed interval UDP's the lost
packets only to the receivers that lost the packets. Keep iterating
until everyone has everything. Once you are down to a few clients and
a few packets you can switch away from UDP and blast the remaining
packets through more reliable methods if you want to truncate the long
tail of errors. The first time out you will give 80% of the data to 80%
of the clients and it will degrade quickly form there...

Also you are probably doing to much with your packets at receive time.
Just retrieve them from the UDP listener and move them to a queue.
Your machine is way faster than the measly 100MBit/sec UDP can can
achieve so you should be able to keep up with it just fine. Spawn
another thread to handle the data, or deal with it later if it is not
to large.

If that does not work, by a better router/switch. Some of the cheaper
ones have a hard time with UDP in general.

David Tucker

09-30-2007, 10:36 AM

unix

Re: polling

<david.tucker@goliathindustries.com> wrote in message
news:1163172565.412885.214860@b28g2000cwb.googlegroups.com...[color=blue]
>
> Guddu wrote:[color=green]
>> To put it briefly,
>> can we use polling to find whether UDP packets are being dropped at the
>> UDP socket buffer? If so how ?[/color]
>
> You have UDP all wrong, it is really only useful for talking to a lot
> of clients at once. For example if you want to push the same file out
> to 20 machines, in theory UDP is 20 times faster than with "normal"
> TCP/IP communications. (Theory only because UDP drops packets like a
> dog).
>[/color]
You're talking about UDP broadcasts here? I think UDP is useful in many
other applications where the overhead of TCP is problematic.

[snip][color=blue]
>
> Also you are probably doing to much with your packets at receive time.
> Just retrieve them from the UDP listener and move them to a queue.
> Your machine is way faster than the measly 100MBit/sec UDP can can
> achieve so you should be able to keep up with it just fine. Spawn
> another thread to handle the data, or deal with it later if it is not
> to large.
>[/color]
Totally agree about the queue thing but how do you know his machine is that
fast? This is .embedded so it's possible he has a pretty wimpy processor. I
know I do.

Andrew

09-30-2007, 10:36 AM

unix

Re: polling

[email]david.tucker@goliathindustries.com[/email] wrote:
[color=blue]
> You have UDP all wrong, it is really only useful for talking to a lot
> of clients at once. For example if you want to push the same file out
> to 20 machines, in theory UDP is 20 times faster than with "normal"
> TCP/IP communications. (Theory only because UDP drops packets like a
> dog).[/color]

This is very misleading. UDP doesn't inherently drop packets, that
depends on the underlying transport. On a good network with sufficiently
powerful machines there will be zero packet loss. On a lossy network,
even TCP/IP performance will suffer due to the retransmits. You can't
get something for nothing.

The correct way to put it is that UDP provides no delivery guarantees.
[color=blue]
> If that does not work, by a better router/switch. Some of the cheaper
> ones have a hard time with UDP in general.[/color]

Weird suggestion, there. A switch certainly does not care about anything
above the ethernet layer so why would it care about UDP ? Even routers
are mostly concerned with the IP layer only.

09-30-2007, 10:37 AM

unix

Re: polling

rTrenado wrote:
[color=blue]
> There is however one way (that I am familiar with) to know if packets
> are being lost on a specific UDP port.
>[/color]

Which way is that?

09-30-2007, 10:37 AM

unix

Re: polling

VJ wrote:[color=blue]
> rTrenado wrote:
>[color=green]
>> There is however one way (that I am familiar with) to know if packets
>> are being lost on a specific UDP port.
>>[/color]
>
> Which way is that?[/color]

Monitor UDP stats via SNMP.

Dave

09-30-2007, 10:37 AM

unix

Re: polling

rTrenado wrote:[color=blue]
> UDP stands for User Datagram Protocol, its main goal is to send
> messaged with a minimum of protocol mechanism, and the delivery and
> duplicate protection are not guaranteed. So, if packets are being lost
> or "dropped" it is because something is happening on the transpport,
> network or phy layers of the local client (or remote host for that
> matter). Transport is where UDP is located, and if the receiver is not
> getting UDP messages from a remote host it is possibly that the client
> did not bind correctly to the UDP port to listen. If the problem is at
> the network layer it could be because the remote host cannot reach the
> UDP client. On the physical, well... maybe ARP is not working on the
> client side (if it is ethernet of course)... I am just guessing...
>
> So the answer is, if the UDP data is on the socket buffer it means that
> the UDP packet made it to the receiver end and it was not dropped. If
> it is in fact dropped you dont get anything out of the socket buffer
> for that packet.
>
> There is however one way (that I am familiar with) to know if packets
> are being lost on a specific UDP port.
>[/color]

Hi ,
Please tell me what is the way to know if packets are being lost on a
specific UDP Port. netstat can tell about all UDP packets dropped at
all the ports.
If I can find if packets are being dropped at the specific port, my
purpose would be solved.

Regards,
Vishal
[color=blue]
> Rene
>
>[/color]

09-30-2007, 10:37 AM

unix

Re: polling

> If I can find if packets are being dropped at the specific port, my[color=blue]
> purpose would be solved.[/color]

What do you mean by "packets being dropped at the specific port" ? If a
packet gets lost in the transport, the receiving port/machine sees
nothing of it and the sending port/machine never knows that it did not
reach the destination. So there is _no_ way to detect the loss. (Unless
a higher protocol is established that performs a handshake. But this is
not "UDP" but something that _uses_ UDP).

-Michael

09-30-2007, 10:37 AM

unix

Re: polling

rTrenado wrote:[color=blue]
> To find out if packet are being dropped the easiest way is to create a
> script and poll netstat.[/color]

How should netstat know about lost packets ? A UDP packet is delivered
without any acknowledgment by the receiver. So the loss of a packet
can't be detected at all, unless some higher level protocol is k known
to the detector.

-Michael

09-30-2007, 10:37 AM

unix

Re: polling

rTrenado wrote:[color=blue]
> netstat will tell you what UDP ports are in listening mode, plus it
> will tell you how many packets were lost at the time you call it.[/color]

Of course it does tell you how many packets arrived at this port, but as
it does not know how many were sent to that port (possibly from multiple
other computes), it can't tell you how many were lost.

-Michael

09-30-2007, 10:37 AM

unix

Re: polling

> I was referring to[color=blue]
> dropped packets.[/color]

OK. I suppose dropped packets are those received by the IP stack from
the wire that were not digested by the software that requested opening
the port. I don't know what this number is useful or other than for
debugging the local software.