gen_tcp:recv - last segement when closed port

[Valentin Micic]

> Maybe you're thinking of TCP reset (RST),

No I was thinking about FIN-1, and yes, I was wrong, as far as protocol is 
concerned .
Although, this is not relevant to the case in question, consider a sequence 
diagram below:

A --------512By------------>B ---- reads 128By -------> App
A <------64------------------B <----------64By---------- App
                                              B -----reads 128By -------> 
App
A ----------FIN-1-----------> B <-----------64By--------- App
A <--------64By--------------|
A ---------RESET----------> B Remaining 256 Bytes are lost
.
.
.

If application read only fraction of the data available, as per your 
assertion, arrival of FIN-1 shall not inform App about remote closure. This 
leaves App free to send any kind of data back to the remote peer. However, 
when remote peer receives such data, considering that it is in FIN-WAIT 
state, it has no choice but to reply with RESET, and hence force receive 
buffer on App side to flush all the data. I had a situation like this many 
years ago, and assocciated the loss of data to close request, while infact, 
it was App sending data causing remote peer to issue RESET request, and 
hence flushing the tcp buffer on App side.
Thank you for making me think it through :-).

V.


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


> "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
>