gen_tcp:recv - last segement when closed port
Sun Mar 12 10:59:58 CET 2006
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".
Per Hedeland ha scritto:
> "Valentin Micic" <> 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
> 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?
More information about the erlang-questions