UDP over v6: payload truncated at 1024 bytes

Tony Rogvall tony@REDACTED
Sun Apr 11 01:13:42 CEST 2004

måndagen den 5 april 2004 kl 15.26 skrev Luke Gorrie:

> Fredrik Thulin <ft@REDACTED> writes:
>> So it seems Erlang uses a 8k buffer for v4 and 1k buffer for v6. That 
>> does not
>> seem right. In fact, since the biggest UDP datagram size is 64k I 
>> think the
>> buffer ought to be 64k for both v4 and v6.
> That sounds like the most reasonable default to me too.
> You can set this in your code when you open the sockets. Just include
> this option in gen_udp:open -
>   {recbuf, 65535}

Well, I think that the recbuf option is mainly used by TCP, however the 
side effect of the recbuf
options is to align the 'buffer' option to be at least the size of 
recbuf. In other words the
{buffer, 8192} should be used in this case. The recbuf option should 
only be used (my opinion) when
kernel buffer space is low (think proxy/server with lot of persistent 
connections). Also if one touch the
recbuf option ONCE then one will affect the sliding window behaviour 
(at least under linux) and then
one has to adjust it manually !? There is no way to reset the recbuf to 
the default (i.e let OS handle it)

The reason why IPV4 has a reasonable default of 8k is found in the code 
for inet_udp.erl not in
the driver. For some other reason (lack of time or whatever) the code 
in inet6_udp.erl was not
updated with the very same default (uses the drivers default of 1k).

On the allocation issue.

When using packet option for TCP the driver will buffer until all bytes 
in the packet has arrived.
This means that a buffer is use for storing the partial data. Same goes 
for calling recv in passive mode.

For UDP NO buffer is pre allocated, the value of the buffer option is 
used to allocate a buffer used
for doing the actual recvfrom system call. Then the data is delivered 
and the buffer is released (by the driver).
(Even some nifty buffer pool code handling effective buffer reuse :-)

Hope it explains things :-)


More information about the erlang-questions mailing list