[erlang-questions] Mochiwebsockets was Re: Long polling

[Gordon Guthrie]

Gleb

> It can be important. Some browsers limit number of concurrent
> connections opened to a single host to two. This means that if you
> would have two long-polling connections opened at the same time, you
> won't be able to do a simple AJAX request on those browser (it will

That's from a different page so it won't affect the softphone.

> So it seems that you don't need any complex solution. Most probably a
> simple long-polling XmlHttpRequest with a 30 seconds connection
> cycling (to work through proxies) should work well for you. If you
> don't care about proxies ~50 seconds will be better choice to preserve
> bandwidth and CPU on server.

That's kinda what I was thinking, open a connection, hang it on a
receive, if the server needs to talk to the phone get the connection
to return {msg: "are you there?"} client sends back {msg: "yup"} then
job's a good un.

I need to write the 'keep alive' case when the connection breaks down
at the same time as the inbound call asks for it, but that's OK.

So 30 secs is the right time for a long connection - at the moment we
use 600 secs and get intermittent disconnection problems - usually
when using a mobile internet connection -  mebbies I should dial it
down to 30 secs.

Gordon

On 20 July 2012 09:36, Gleb Peregud <gleber.p@REDACTED> wrote:
> On Fri, Jul 20, 2012 at 10:24 AM, Gordon Guthrie <gordon@REDACTED> wrote:
>> There are a couple of complications - we already use one long-poll for
>> server-to-client updates - in that case the client posts changes and
>> the server works on them and then streams out updates on a separate
>> long-poll. Lets put that aside and focus on this use case.
>
> It can be important. Some browsers limit number of concurrent
> connections opened to a single host to two. This means that if you
> would have two long-polling connections opened at the same time, you
> won't be able to do a simple AJAX request on those browser (it will
> queue after long-polling connections and possibly timeout). Afair
> older IE had this problem, I don't recall in more details which one
> was it.
>
>> Single domain
>> It is a single registration event - ...
>> It's the server saying "are you still there?"
>> Needs to be reliable. ...
>> Yeah, lots of JQuery - ...
>> I will tolerate any size of code base if it is encapsulated nicely. ...
>
> So it seems that you don't need any complex solution. Most probably a
> simple long-polling XmlHttpRequest with a 30 seconds connection
> cycling (to work through proxies) should work well for you. If you
> don't care about proxies ~50 seconds will be better choice to preserve
> bandwidth and CPU on server.
>
> Essentially you could take parts of Bullet which does cycle
> connections, while jQuery handles most intricacies related to error
> handling.
>
>> What would the benefits of Cowboy over Mochiweb be?
>
> Since it seems that you don't need websockets after all, if Mochiweb
> works well there is no real need to switch.
>
> Cheers,
> Gleb