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.

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

Ger>

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.

h> > If I can find if packets are being dropped at the specific port, my

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