[erlang-questions] Long polling

[Gordon Guthrie]

Kaiduanx

Essentially, is this testing how long different bits of kit will
tolerate long-open connections?

We already have one long remoting connection but this pushes updates
to the front-end and the front-end polls it - and is fairly
straightforward and works well.

For what I am doing now I need to get a response back from the
browser, so I think I will need another approach.

Gordon

On 17 July 2012 16:34, Kaiduan Xie <kaiduanx@REDACTED> wrote:
> I assume that you are talking about the TCP NAT keep-alive time.
> Please check the following paper,
>
> http://nutss.gforge.cis.cornell.edu/stunt.php
> http://saikat.guha.cc/stunt-results.php?
>
> Please look at the Timer section in the survey.
>
> Why you need to use HTTP long poll? You can just use a persistent
> TCP/TLS connection and periodically send keep-alive message to keep
> the TCP/TLS connection alive.
>
> Or you can use Websocket, it is designed to replace long poll.
>
> /Kaiduan
>
> On Tue, Jul 17, 2012 at 11:01 AM, Gleb Peregud <gleber.p@REDACTED> wrote:
>> On Tue, Jul 17, 2012 at 4:57 PM, Gordon Guthrie <gordon@REDACTED> wrote:
>>> Folks
>>>
>>> I am building a softphone which needs to register with the server to say "I
>>> am available" for incoming calls.
>>>
>>> So it makes an HTTP POST request to the server and that notifies the
>>> softphone gen_srv that is is available.
>>>
>>> At that point I leave the TCP request hanging on a receive waiting for a
>>> notification that the socket has been torn down (and which point it
>>> unregisters the phone).
>>>
>>> My question is: how long can I leave the request up? Infinity? or do I need
>>> to have a timeout/reregister cycle setup?
>>
>> You have to cycle it. Some proxies timeout connections after 30
>> seconds, some after 45 some after 60. It is very tricky to get it
>> right for all browsers and all platforms. Generally if you want a
>> robust solution use something like SockJS or Socket.IO or Bullet.
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions