[erlang-questions] Can gen_tcp:close() close a socket which is still sending?

[Tony Rogvall]

There are two buffers between you and the wire. First there is the  
Socket/Port buffer and
then there is the operating system socket buffer.

When you send data from Erlang the data that could not be transmitted  
directly is
queued for delivery when more kernel buffer space is available.

After you issue a gen_tcp:close then if the server side is really slow  
and do not process any data for
more than 5 seconds then the socket is closed any way.
My guess is that you send some buffer that is queued in the operating  
system buffer and then
you call close. What happens then is up to the tcp implementation. Are  
you using Windows ?

The "safe" way to terminate a sending socket is to use shutdown(S,  
write) and then wait
for the server side to close the connection.
The shutdown interface will also wait until all data queued in the  
Port/socket is written to the
operating system socket before issuing the low level shutdown.

Hope this will lead you forward.

/Tony




On 14 jun 2009, at 03.08, John Haugeland wrote:

> I have a defect that I don't fully understand.  When I dispatch
> something by gen_tcp:send(...), I follow through with :close().
> However, there's a sporadic pattern of the data getting cut off early.
> If I inject a delay between them, the problem disappears.
>
> This seems to imply that :close() can close a socket which is still
> sending data.  That isn't what I would have expected by comparison
> from other languages, so I'm not entirely convinced I've understood
> this correctly.
>
> Is it safe to call :close() immediately after a large :send()?  If
> not, what does one do instead?
>
> ________________________________________________________________
> erlang-questions mailing list. See http://www.erlang.org/faq.html
> erlang-questions (at) erlang.org
>