udp recvfrom and sendto

[realcr]

Hi everyone.

I was recently using some udp sockets , and after some programming I was wondering how recvfrom and sendto functions
are going to behave on some situations.
I know that TCP is a stream protocol , therefore a "send" call on one side can be equivalent to several "recv" calls on the other side.
Is it the same with UDP and the recvfrom function?

I got the same question for the sendto function. Someone told me that 576 is a safe number of bytes for sending UDP packets. I have no idea where does that number come from, and can I actually trust sendto function to send everything if the size of data is 576 or less.

I will appreciate any opinions on that so I can write some robust code.
great thanks,

realcr.

[Adamanteus]

Transmission Control Protocol as mean words reassembly pockets, because differ nets have differ pings.

[Tedd]

You can trust udp to send one datagram per sendto operation, you'll need to split your data into datagrams and send them one at a time (otherwise any 'overhang' that gets fragmented on the network will simply disappear.)
Whether or not the datagram is received on the other end is another matter, and there's no indication either. A successful send only means it has been posted - it could get lost or disappear. So you may want to indulge in some kind of acknowledgement, resending if you don't get an 'ack' for the datagram within some timeout period. But that depends what you're doing and whether it's necessary.

How big's a datagram??
512 bytes is sometimes quoted, but I'm sure that's just a rounded-down number that's easier to remember than the real value which is something strange like 576 = max_packet - (UDP_header+IP_header)

WSAStartup gives a 'iMaxUdpDg' value in WSADATA, but apparently you shouldn't use that value, and should use 'getsockopt' instead.
On my machine..

WSAData (v1.1): iMaxUdpDg = 65467
WSAData (v2.2): iMaxUdpDg = 0 (because you shouldn't use it; use getsockopt)

getsockopt: SO_MAX_MSG_SIZE = 65507


I think the 576 is actually a worst case value - it comes from the old ethernet where some switches couldn't handle very large packets. I doubt you'll find many online these days, and you're even less likely to be routed through them. At the network level, 65536 seems to be quite normal (even old network cards generally have a send/recv buffer this size) - subtracting a handful of bytes for the network and protocol headers, you get something around 65500. So I'd be tempted to go with that, or even 32k if you want to be really cautious. Obviously the best thing to do is just try it and see what you get, but that requires you to send quite a few packets and to quite a few different ip addresses.
(Consider current network speeds.. each time you split a packet that adds an extra overhead, so packets must be fairly large to keep up the speed.)

[realcr]

Great thanks Tedd and Admanteus.

Truth is that 576 bytes is more than enough for me. [Assembly programmer after all ...  :U ].
I was more worried about the one datagram per sendto function. After you said I can trust it , I can go back programming.

tnx again,
realcr.