[erlang-questions] Difference in 'close' for gen_tcp recv vs. active

[Jacob]

On 09.04.2014 15:22, Fred Hebert wrote:
> On 04/09, Jacob wrote:
>>
>> It makes a difference here, whether these are FINs or RSTs. Just
>> receiving a FIN from the peer will not stop the OS from accepting for
>> and sending data to the peer.
>>
> 
> it is indeed a FIN for the specific dump I have. It seems to be ACKed
> back (peer = AAAA, our host = BBBB):
> 
> 19:10:55.748018 IP AAAA > BBBB: Flags [.], ack 385, win 62, options [nop,nop,TS val 229098891 ecr 89024950], length 0
> 19:10:56.070985 IP AAAA > BBBB: Flags [F.], seq 156, ack 385, win 62, options [nop,nop,TS val 229098972 ecr 89024950], length 0
> 19:10:56.113998 IP BBBB > AAAA: Flags [.], ack 157, win 12, options [nop,nop,TS val 89024987 ecr 229098972], length 0
> 19:10:56.747853 IP BBBB > AAAA: Flags [P.], seq 385:416, ack 157, win 12, options [nop,nop,TS val 89025050 ecr 229098972], length 31
> 19:10:56.748490 IP AAAA > BBBB: Flags [.], ack 416, win 62, options [nop,nop,TS val 229099141 ecr 89025050], length 0
> 
> It sounds like we're getting dumped into a partially closed session. I'm
> guessing the peer (AAAA) gets stuck into FIN-WAIT-2, waiting for a FIN
> coming from our end (BBBB), giving us a half-open connection.

Yes, most probably.

> 
> What confuses me is given we have the option {exit_on_close, true} being
> set explicitly, we expect Erlang to close that connection once that FIN
> comes in, and not to keep half-open the way it would if we had set
> {exit_on_close, false}, as set in the docs:

How should Erlang know this without calling recv()/read()/... until that
returns 0 or some related error? gen_tcp shouldn't do that in passive
mode, otherwise the were no TCP flow control.

> 
>     {exit_on_close, Boolean}
>     By default this option is set to true.
>     The only reason to set it to false is if you want to
>     continue sending data to the socket after a close has been
>     detected, for instance if the peer has used
>     gen_tcp:shutdown/2 to shutdown the write side.
> 
> Given we have it set to true, we do expect to not be able to keep
> sending data after the fact. We still can, though.


Jacob