polling

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

You're talking about UDP broadcasts here? I think UDP is useful in many
other applications where the overhead of TCP is problematic.

[snip]

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

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.



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.

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.

Rene

Geronimo W. Christ Esq wrote:

Which way is that?

Monitor UDP stats via SNMP.


Dave

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

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

To find out if packet are being dropped the easiest way is to create a
script and poll netstat. Correlate the netstat info with a simple
monitor program to monitor UDP packets... netstat will tell you if
packets are being dropped at socket level whereas the monitor program
will tell you what packets are being received and to which ports at
data link level.

Of course if you already know which UDP port to monitor in advance you
dont need netstat.

To write the monitor program to monitor data link level packets (at
ethernet level for example) use WinPcap for windows, or libpcap for
unix/linux. You will have to do some programming though. At source code
level, you can mix socket programming with libpcap and winpcap calls.

hope this helps
Rene

Michael Schnell wrote:

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

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. Check
the implementation on your OS. You should type netstat -? for help I
think.

This is the output for UDP:

UDP    192.168.1.107:123      *:*
UDP    192.168.1.107:137      *:*
UDP    192.168.1.107:138      *:*
UDP    192.168.1.107:1900     *:*
UDP    192.168.146.1:123      *:*
UDP    192.168.146.1:137      *:*
UDP    192.168.146.1:138      *:*

...

UDP Statistics for IPv4

  Datagrams Received    = 97714
  No Ports              = 1310
  Receive Errors        = 24
  Datagrams Sent        = 247916

Example output for IPv4:

IPv4 Statistics

  Packets Received                   = 128002
  Received Header Errors             = 0
  Received Address Errors            = 413
  Datagrams Forwarded                = 0
  Unknown Protocols Received         = 0
  Received Packets Discarded         = 2

And yes, if packets are NOT reaching the host then there is not a way
to detect them in UDP. However you should keep in mind that there is a
distinction between lost packets and dropped ones. I was referring to
dropped packets.

Rene

Michael Schnell wrote:

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

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.

-Michael

You are right Michael, the number by itself is not that useful however
when you correlate it with the info in the packet sniffer (the UDP
monitor program) then there is when it gets interesting. Monitor this
number to signal the detection of dropped packets & correlate it with
the UDP sniffer to get the actual port the dropped packet was intended
to.

Michael Schnell wrote: