[erlang-bugs] Missing the tcp_closed event

Rickard Green rickard.s.green@REDACTED
Fri May 4 17:53:22 CEST 2007


Sorry for the late answer (the pipe has been full).

Strictly speaking, the missing tcp_closed message is not a bug, and
this behavior is not a new thing. gen_tcp has behaved like this for a
very long time (if not always, at least since R7B).

Why not a bug? If you change the active state from false to once after
the socket has gone into a closed state and after you have been informed
about this, i.e., send has returned {error, closed}, you won't get a
tcp_closed message. This since you will only be informed once, and you
have already been informed that the socket has been closed (informed the
"active false way").

Unfortunately, sending on a socket on windows that has been closed in
the other end will eventually cause gen_tcp:send to return {error,
econnaborted} (where we got {error, closed} on unix). If you after that
change active state from false to once, you will get a tcp_closed
message. This because the socket had not been set into a closed state
during the gen_tcp:send call.

However, we can understand that one might expect a tcp_closed message as
you did and that it would make active once easier to use. The different
behaviors on windows and unix are also unfortunate. We will have a
closer look at these problems and plan to do something about both
problems. This will probably make it into R11B-5.

Regarding the behavior of gen_tcp:send. gen_tcp:send may succeed even if
the other end has closed. If the inet driver succeeds with the send
operation, then gen_tcp:send will succeed. This doesn't imply that the
other end has received the data, only that it has been buffered in the
local tcp send buffer.

BR,
Rickard Green, Erlang/OTP, Ericsson AB.


Mickaël Rémond wrote:
> Hello,
> 
> Can this problem be reproduced by your side ?
> Do you need more informations ?
> 
> Le 13 avr. 07 à 18:23, Mickaël Rémond a écrit :
> 
>> Hello,
>>
>> Alexey managed to find the steps to reproduced the problem.
>> You can have a process managing a TCP connection linked to a dead 
>> socket under the following conditions.
>>
>> 0. Use active once to receive your TCP message to benefit from TCP 
>> regulation
>> 1. Assume we have a socket in {Active, false} state
>> 2. Close its connection from the other end
>> 3. call gen_tcp:send on the socket two times (It returns ok on the 
>> first send, which is also wrong. The problem happens only with two or 
>> more sends).
>> 4. swith to {active, once} state
>> => no {tcp_closed, ...} message is received by the process.
>>
>> If you check the state of your port after step 4 (for example with 
>> inet:peername) you will receive an error enotconn.
>>
>> You end up with a stuck process. If you send messages to the process 
>> queue to send messages on the socket it will accumulate indefinitely.
>>
>> Please, let me know if we can do something more to help.
>>
>> -- 
>> Mickaël Rémond
>>  http://www.process-one.net/
>>
>>
>>
>> _______________________________________________
>> erlang-bugs mailing list
>> erlang-bugs@REDACTED <mailto:erlang-bugs@REDACTED>
>> http://www.erlang.org/mailman/listinfo/erlang-bugs
> 
> -- 
> Mickaël Rémond
>  http://www.process-one.net/
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> erlang-bugs mailing list
> erlang-bugs@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-bugs










More information about the erlang-bugs mailing list