-1

I need to write a couple of C++ applications on Linux, one to receive data via UDP and the second TCP.

The only thing I'm unsure about is regarding the buffer.

How do I choose what size buffer?

If I make the buffer large enough, am I guaranteed to avoid scenarios where half of a packet is at the end of my buffer and I need to copy the bytes to the beginning and then receive the remaining half of the packet?

I am going to use the Linux socket API functions if it matters.

red0ct
  • 4,840
  • 3
  • 17
  • 44
intrigued_66
  • 16,082
  • 51
  • 118
  • 189
  • Can you provide your current attempt?: https://stackoverflow.com/help/how-to-ask – fugiefire Aug 20 '19 at 01:21
  • Ha! You're asking something that has been debated for years without an actual answer: https://stackoverflow.com/questions/1098897/what-is-the-largest-safe-udp-packet-size-on-the-internet – Marco Bonelli Aug 20 '19 at 01:35
  • 1
    Then why didn't you mark this as `c++`? – Deanie Aug 20 '19 at 01:35
  • 1
    If you're talking about socket receive buffers in the kernel, (1) this cannot happen in UDP and (2) it can't really happen in TCP either as the packet and segment boundries are obliterated by the API. If you're talking about buffers in your application, you should allocate a buffer one larger than the largest expected datagram for UDP, and the largest buffer you can afford for TCP. Please clarify your question. @MarcoBonelli That question is about UDP message sizes, not buffers. – user207421 Aug 20 '19 at 01:41
  • 1
    @Deanie because it's not a C++ question...... – intrigued_66 Aug 20 '19 at 02:34
  • @fugiefire My current attempt at my buffer size?? – intrigued_66 Aug 20 '19 at 02:35
  • @user207421 Yes I am referring to my application. Although actually, why would I need two buffers? Surely i'd just make the kernel buffer larger-enough? – intrigued_66 Aug 20 '19 at 02:36
  • You have to read into something in your application, a byte array, and it has to be some size. – user207421 Aug 20 '19 at 04:36
  • @mezamorphic `I need to write a couple of C++ applications`... sounds like you want `c++`. They are not the same language! – Deanie Aug 20 '19 at 14:50

2 Answers2

3

If I make the buffer large enough, am I guaranteed to avoid scenarios where half of a packet is at the end of my buffer and I need to copy the bytes to the beginning and then receive the remaining half of the packet?

Based on the above paragraph, I'm going to surmise that the buffer you are referring to is the application-space buffer that you pass into your recv() calls, and not the in-kernel buffer that the networking stack maintains on your application's behalf.

For UDP, the answer is simple: Your buffer needs to be large enough to hold the largest possible datagram you expect to receive. Since UDP datagrams are typically less than 1500 bytes (to avoid fragmentation) and in all cases are <= 65507 bytes (since that is the maximum datagram size the UDP protocol supports), you can always make your receive buffer 65507 bytes long, or smaller if you want to save a bit on RAM usage.

For TCP, the protocol is stream-based, so the amount of data written in to your recv-buffer by a given recv() call is unrelated to packet sizes. Another consequence of TCP being stream-based is that it doesn't do any message-framing -- that means you will have to handle partial messages regardless of how big or small you make your buffer. The only advantage of a larger TCP buffer is that it's a bit more efficient to handle more bytes at a time instead of fewer, again at the cost of using a little more RAM.

Jeremy Friesner
  • 70,199
  • 15
  • 131
  • 234
1

If I make the buffer large enough, am I guaranteed to avoid scenarios where half of a packet is at the end of my buffer and I need to copy the bytes to the beginning and then receive the remaining half of the packet?

For TCP: It doesn't matter. Packets are an implementation detail. The application doesn't even have to think about them. TCP is a byte-stream protocol and all you ever get from the API is a stream of bytes. Message boundaries are never preserved.

For UDP: Packets are still an implementation detail. You send and receive datagrams. Your read function always gets an entire datagram so long as your buffer is as large as the largest datagram your application protocol supports.

David Schwartz
  • 179,497
  • 17
  • 214
  • 278