gen_tcp:recv - last segement when closed port

[Valentin Micic]

It's been a long time since I've been thinking about this, but as much as I 
could remember the remote close request is treated as OUT-OF-BAND data, 
which means that it will bypass anything that exist in/on protocol stack's 
buffer. So, if there is, say, 1200 octets in buffer, and you read 348, and 
before you managed to read remaining octets, TCP_CLOSE request arrives, you 
will lose unread data. This has nothing to do with ERLANG, but with the way 
tcp works.
But then again, it's been a long time, and my memory might not serve me 
correctly.

V.

----- Original Message ----- 
From: "Per Hedeland" <hedeland@REDACTED>
To: <valentin@REDACTED>
Cc: <erlang-questions@REDACTED>; <johan@REDACTED>
Sent: Saturday, March 11, 2006 3:55 PM
Subject: Re: gen_tcp:recv - last segement when closed port


> "Valentin Micic" <valentin@REDACTED> wrote:
>>
>>Could it be that default receive buffer is somehow set to 1K?. If so, try 
>>to
>>increase it using:
>>inet:setopts( Sock, [{recbuf, Integer}] ).
>
> Well, that a) shouldn't be needed, b) may just hide the bug if there is
> one (as Johan suggested), and c) may result in really bad performance if
> you set it to something just big enough to handle a single packet (like
> Johan did:-). You can avoid c) by using the undocumented 'buffer' option
> instead of 'recbuf'.
>
> (The recbuf/sndbuf options are "supposed" to set the size of the
> kernel-level buffers where data is stored until collected via the socket
> - recbuf directly affects the size of the TCP receive window. As a side
> effect, I'm not really sure why this is done, setting recbuf will also
> make sure the user-level buffer where data is stored after it has been
> collected via the socket is at least as big. It's the size of the latter
> that defaults to 1024 (the kernel-level buffer is generally way bigger),
> and which may be relevant for Johan's problem. The 'buffer' option will
> set only the size of the user-level buffer. Of course the idea is that
> the Erlang programmer should never need to worry about these nitty-
> gritty details.:-)
>
> --Per
>