Re: UDP packets

Jack <junw2000@xxxxxxxxx> wrote:

I wrote two small programs. One is server(use recvfrom), one is
client(use sendto).

Sounds a bit like netperf UDP_STREAM :)

Both the server and client run on the same machine. Each time the
client runs, it sends out 100000 UDP packets within 2 min.

So, 100000 UDP _datagrams_ (UDP packets are called datagrams :) in 120
seconds, or ~834 datagrams per second. Not all that much really.

The size of each packet is 1KB. Maybe it is too much, right?

Well, depends on how long your receiver's service time happens to be
and/or how slow/fast the link between the two happens to be.

I use setsockopt() to change the SO_RCVBUF. I found that even if I
make the buffer very larger, it does not help, on the contrary, more
packets are dropped. Even for the same buffer size, the result
varies. Do I need to adjust SO_SNDBUF? If SO_SNDBUF is too small,
what will happen? Another question is if the system's udp_max_buf
is 250K, does it mean that SO_SNDBUF and SO_RCVBUF share the same
250K space?

In broad handwaving terms, and as implied by other posts, the receiver
appears to be slower than the sender. Since UDP provides no flow
control, if the sender is faster than the receiver, packets will queue
in the SO_RCVBUF or its platform-specific equivalent. If the sender
keeps sending then the SO_RCVBUF will fill and UDP datagrams will be
lost.

Now, if you simply increase the SO_RCVBUF, it will only "work" if the
_sustained_ send rate by the sender is lower than the sustained
service rate of the receiver - ie it only really works when the
receiver is actually faster than the sender, and the drops were only
the result of occasional hiccups in the receiver - say being
timesliced-out.

If you cannot _guarantee_ your receive side is faster than your send
side, you _must_ provide some sort of flow-control of your own device.

Of course, and again as already suggested, even if the receiver is
'fast enough' you still have to worry about UDP datagrams being
dropped for other reasons - say data corruption or a link being down
for a while or whatnot.

rick jones
--
denial, anger, bargaining, depression, acceptance, rebirth...
where do you want to be today?
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...
.

Relevant Pages

  • Re: CSocketFiles / CArchive vs Raw Buffer Manipulation
    ... such as network packet transmission. ... UDP within a LAN often gives the effective illusion that it is reliable. ... fail without warning of any sort to either the sender or the receiver. ...
    (microsoft.public.vc.mfc)
  • Re: Question on select() and sockets
    ... dropping of received datagrams'. ... datagrams on their way from the sender to the receiver (even this is ... Note that it doesn't see these are the only ways in which UDP is ...
    (comp.unix.programmer)
  • Re: Almost 80% of UDP packets dropped
    ... UDP is connectionless. ... There is no way for sender to know that it must ... stop sending UDP packets because receiver cannot keep up. ...
    (Linux-Kernel)
  • Re: Almost 80% of UDP packets dropped
    ... > UDP is connectionless. ... There is no way for sender to know that it must ... > stop sending UDP packets because receiver cannot keep up. ...
    (Linux-Kernel)
  • Re: A question regarding MTU: how it can effect TCP performance + other queries
    ... my question is not regarding TCP. ... My concern is about UDP throughput that why UDP Iperf is reporting UDP ... Sending 1470 byte datagrams ... did not receive ack of last datagram after 10 tries. ...
    (microsoft.public.development.device.drivers)