[erlang-questions] Can gen_tcp:close() close a socket which is still sending?
Sun Jun 14 12:03:52 CEST 2009
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
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.
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
More information about the erlang-questions