Re: polling


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

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

.

Relevant Pages

  • Re: UPD better than TCP in streaming video/audio ?
    ... > UDP gains speed over TCP because it carries no information that would ... it doesn't even know that packets were lost. ... which is perfect for UDP. ... > Finally, there's the possibility of multicast data - for instance, a live ...
    (microsoft.public.win32.programmer.networks)
  • Re: Linux equivalent for ioctlsocket(FIONREAD) on datagram sockets
    ... Imagine that fast CPU sends a burst of UDP ... spirit of UDP standard should do in that particular case? ... blocking a clling thread until the NIC hardware ... reads one or more packets from socket's send buffer freeing up space ...
    (comp.os.linux.development.apps)
  • Re: NTP and Firewall help needed.
    ... >>port 123 for udp and tcp. ... The action here is applied for packets that fall off ... > - ACCEPT any and all traffic coming from the localhost interface ...
    (comp.os.linux.setup)
  • Re: Possible bug in .Net 2.0 udp sockets?
    ... You won't miss any UDP packets with a buffer that large! ... R> I called BeginReceiveFrom() several times on purpose, ... If you don't do that, indeed, UDP stack can drop packets. ... it stores it in the queue. ...
    (microsoft.public.dotnet.framework)
  • Re: Update: UDP 770 Potential Worm
    ... > the network immediately after the 'attack', ... were no packets indicating some form of replication. ... I noticed that the UDP ... > of the UDP datagrams is the IP address of the proxy? ...
    (Incidents)