gen_tcp:recv - last segement when closed port

[Corrado Santoro]

Hi all,

as far as I remember, sometimes ago I had a similar problem in a C 
program, so, even if Per argue that TCP promises a reliable byte stream 
(and this is true), I think that there is a sort of strange behaviour in 
handling disconnection conditions (I experienced this problem on Linux). 
I solved the problem by readling a byte at time, but undoubtedly this is 
not an elegant solution.

It could be related to the fact that, if you have 300 final bytes in the 
buffer and perform a read requesting 1024 bytes, the socket 
implementation says "no, I can't give you the buffer you request because 
the socket has been closed".

--Corrado

Per Hedeland ha scritto:
> "Valentin Micic" <valentin@REDACTED> wrote:
>> 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.
> 
> I'm afraid I have to agree with that - your memory is not serving you
> correctly. TCP promises to deliver a reliable byte stream, and with the
> socket interface you can read it however you want, and still get all the
> bytes that the remote wrote before closing. Many protocols rely on this,
> notably "plain" HTTP/1.0 as in Johan's case. If there is a problem here,
> it is either in Erlang's inet_drv driver or in the TCP/socket
> implementation that Johan is using (but the latter is extremely
> unlikely, even on that particular OS).
> 
> Maybe you're thinking of TCP reset (RST), which will indeed in common
> implementations throw away any unread data. And come to think of it,
> it's not uncommon that "that particular OS" seems to think that RST is
> the proper way to close a TCP session... Johan, you're not seeing an RST
> from the server in the traces, are you?
> 
> --Per