TCP Buffer Size of 1536 - Is this an arbitrary value?

[linfan68]

I found this magical number in:

moddable/modules/io/socket/lin/tcp.c

Line 41 in 2945c5d

#define kBufferSize (1536)

This constant is used to define the size of TCP read buffers in socket communication. What struck me as odd is that this value seems to be just slightly larger than the typical Maximum Transmission Unit (MTU) size, which is usually 1500 bytes for Ethernet.

Although TCP data is buffered in the kernel, I can imagine a scenario where if a JS thread needs to send large data, it would have to break the data into chunks of 1536 bytes to send to tcp.c. If the synchronization between JS and Native is not perfect, the kernel might split the 1536-byte packet into two packets of 1460 + 76 bytes, wasting nearly half of the bandwidth

[phoddie]

Good question. Let me answer with a bit of a digression.

The number is arbitrary, but not entirely so. The 419 TCP socket is designed to be used in the simulator. The relatively small buffer size reflects the TCP buffer on microcontrollers using the lwip network stack. Even some lwip deployments have a bigger buffer (on ESP32, I've seen it be up to 8 KB). Keeping it small tends to force code to take the buffer size into account – if it doesn't, it will hit a buffer overflow pretty quickly. That's faster to debug on the simulator than the device, so this tends to catch and correct issues faster.

But, of course, when not simulating a small device, the small buffer size can significantly reduce network throughput. And a poorly chosen buffer size can lead to extra packets being transmitted.

I think the reasonable solution would be to add a configuration define to set the buffer size (current defined with kBufferSize). A host, like your new embedded Linux host, can set that value as appropriate.

This approach would also let you tune the buffer size to match the MTU size (or a multiple of the MTU size). Whether that makes a significant efficiency improvement could depend on the buffering that takes place in the networking stack though.