[99s-extend] timeout in cowboy loop handler

akonsu akonsu at gmail.com
Wed Oct 16 06:12:29 CEST 2013


thanks. one more question if you do not mind. you say that we need timeouts
when the client does not notify us when it dies. but then you say that if
the client dies then the socket write will fail. to me this sounds like a
contradiction. would you please clarify?

(I assume that this is the problem that we are discussing:
http://stackoverflow.com/questions/283375/detecting-tcp-client-disconnect,
right?)


2013/10/16 Loïc Hoguin <essen at ninenines.eu>

> On 10/16/2013 05:48 AM, akonsu wrote:
>
>> 1. do you mean that there is no way on the server side to tell if the
>> client has disconnected?
>>
>
> There are ways, and Cowboy will happily detect them. There's also the
> problem that a side may be closed without the other side knowing about it,
> which is why you need timeouts.
>
>
>  2. if I use a normal handler, I will still run into the same problem, it
>> does not matter which handler I use, from the standpoint of deciding
>> whether the client is still there, right?
>>
>
> If the client is gone, the send will fail. Normal handlers are pretty much
> the same except they don't have a timeout, because your code has an
> explicit end.
>
>  I am confused as to how I can implement my streaming and not drop the
>> connection on each client and yet make sure I do close the connections
>> when the clients disconnect...
>>
>>
>> 2013/10/15 Loïc Hoguin <essen at ninenines.eu <mailto:essen at ninenines.eu>>
>>
>>
>>     Infinite is bad practice, yes. Infinite means some connections will
>>     *never* be closed, eating FDs and memory for nothing.
>>
>>     I'm not sure why you want to receive messages, you could just use a
>>     normal handler that asks for more data, sends it, ask for more data,
>>     sends it, etc.
>>
>>
>
> --
> Loïc Hoguin
> Erlang Cowboy
> Nine Nines
> http://ninenines.eu
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ninenines.eu/archives/extend/attachments/20131016/edbc349c/attachment.html>


More information about the Extend mailing list