1

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.

Robbie Mckennie
  • 405
  • 2
  • 16
  • 1
    UDP datagrams are sent atomically, they won't be joined on receipt. (but may be truncated by a short `recv`) – Hasturkun Jul 21 '13 at 12:18
  • 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 Jul 21 '13 at 12:30
  • @RobbieMckennie: Yes, that is how any `SOCK_DGRAM` socket operates. – caf Jul 21 '13 at 13:23
  • 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 Jul 21 '13 at 18:40
  • 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 Jul 21 '13 at 18:45

1 Answers1

-1

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.

ja_mesa
  • 1,971
  • 1
  • 11
  • 7
  • I feel like you totally missed the scope of my question. I understand how UDP works, i'm strictly asking about how the kernel deals with taking my information and packing it into datagrams. – Robbie Mckennie Jul 21 '13 at 12:32
  • 1
    @RobbieMckennie: usually there's a direct 1-1 relation between `send` calls and datagrams being sent. (there's a `MSG_MORE` flag that alters this behavior, but I don't think you're concerned with that one) – Hasturkun Jul 21 '13 at 12:59
  • @RobbieMckennie: Oh, sorry about that, I misunderstood the scope of the question. – ja_mesa Jul 21 '13 at 13:01
  • @Hasturkun Fantastic, that's exactly what i needed to know – Robbie Mckennie Jul 21 '13 at 13:04
  • @RobbieMckennie May be [this](http://stackoverflow.com/questions/14407452/path-of-udp-packet-in-linux-kernel) is what you're looking for. – ja_mesa Jul 21 '13 at 13:10