How does Linux buffer datagram sockets?

1
votes

As a personal project i'm attempting to engineer a network time sync protocol, using C. One thing that is really fazing me is my total lack of knowledge about how my kernel will buffer my udp packets. I want to make sure that packets will send exactly when i want them to, and not be buffered to a certain block size or whatever. I also want to know if the buffer how i can ensure the division between datagrams, as i have seen to way to do this yet. I have read through a good amount of Beej's Guide to Network Programming, but i haven't found anything there to help me.

EDIT: I understand how UDP itself works. I am only asking about the properties of the kernel socket interface.

1
clinuxsockets
UDP datagrams are sent atomically, they won't be joined on receipt. (but may be truncated by a short recv) - Hasturkun
I know the datagrams themselves are sent like that, but i don't understand what rules govern when the buffer is flushed prior to actually sending them. Are you saying that individual datagrams are stored separately in the receiving buffer, and read off one per recv call? - Robbie Mckennie
@RobbieMckennie: Yes, that is how any SOCK_DGRAM socket operates. - caf
You might want to ask this question on the ptpv2 developer's mailing list, since they have dealt with this issue while developing PTPD. In particular I recall reading that they found it impossible (on standard hardware) to determine an outgoing packet's exact send-time until after the packet has been sent, and thus they have to transmit the send-time to the remote peer separately as part of a "follow up packet" that they send shortly after the first packet. - Jeremy Friesner
Btw my understanding is that there is no equivalent to Nagle's algorithm for UDP, but your UDP packet does get placed into an in-kernel FIFO queue that the network driver drains as fast as it can. That means that if you send() a UDP packet it may get sent right away (if the kernel's queue was empty), or (if there are already other packets in the kernel's FIFO queue) it won't get sent until after the others have been sent. - Jeremy Friesner

1 Answers

-1
votes

If the packet sequence and/or the reception of all packet is a matter, then you need to implement a protocol, that is, the sender will send a packet and it will wait until it receives the ACK's packet (an acknowledge of reception) back from the receiver. If the sender does not received the ACK packet in a reasonable time it will resend the same packet. Also, in the packet's data you could include a packet ID, an integer which increments for every packet sent; with this ID you avoid packet duplication. This is how, roughly, the UDP packets flow.

UDP is NOT connection oriented, you don't have a connection between server and client, client sends packet and server receives them, without any guarantee they get there neither they get in the order they were sent. For connection oriented protocols consider the use of TCP.