does faye support long polling??

[Jordan Lance]

Does Faye support long polling as described in below image?

Source: http://meteorserver.org/interaction-modes/ 

all below the page. 

"Sounds like it's time for a happy middle ground between streaming and short polling, doesn't it? Well, long polling may well fit the bill. The client initiates a request, and if the server has events pending, it sends them and closes the connection, much like short polling. But if the server does not have any events waiting, it holds the connection open until an event occurs, at which point it send the event and closes the connection. The client can then initiate a new connection immediately, since all the waiting is done at the server end.
The obvious benefit to this is that the client can treat the interaction as a simple 'request-response' and wait for it to complete before processing it rather than having to sniff the response as it loads. It works through proxies and is more resilient to connections dropping. And since the server is actively closing connections all the time, the chance of long-lived zombie connections is much reduced. On the negative side, there is a need to create and close many more connections than for a stream, one for each event that is sent (but far fewer than for short polling, because the server no longer has the thankless task of responding to millions of repeated requests with "no updated events available"). Also events may be slightly delayed if they occur in rapid succession while the client is reinitiating a new connection after the last update."

I need this behavior to have solid communication, please anyone tell me if its supported I'm 2 days searching for a solution now.

[Sigismond McLaughlin]

Take a look at http://faye.jcoglan.com/architecture.html.

[Jordan Lance]

Still not clear to me if it supports long polling like described in the openings post. I see the different layers and supporting cometD , cometD has long polling but how would one implement long polling in Faye?

This is totally a mystery and key element to solving my issue with "lost" data transfers from server => client.

On Thursday, July 12, 2012 2:57:02 PM UTC+2, Sigi wrote:

Take a look at http://faye.jcoglan.com/architecture.html.

[Lion Vollnhals]

From http://faye.jcoglan.com/architecture.html:

Adapter

The Adapter, as implemented by the NodeAdapter and RackAdapter classes, exposes the Server’s interface over HTTP. It is responsible for serializing and deserialzing messages as JSON and accepting connections over various flavours of HTTP transport:

• Persistent connections using WebSocket
• Long-polling via HTTP POST
• Cross Origin Resource Sharing
• Callback-polling via JSON-P

It clearly states that faye supports multiple styles of transport.

One of those is "Long-polling via HTTP POST".

Regards,

Lion

[Jordan Lance]

Hi Lion, 

Yes but is this documented on how to code a long polling mechanism ? I typed to fast, its stated indeed long polling as you wrote but like 

" The client initiates a request, and if the server has events pending, it sends them and closes the connection, much like short polling. But if the server does not have any events waiting, it holds the connection open until an event occurs, at which point it send the event and closes the connection. The client can then initiate a new connection immediately, since all the waiting is done at the server end." 

How would that look codewise? Im digging the docs but haven't figured this part out yet.. 

Also when you would <reload> a page would this still work? Thx

[Tan Nguyen]

I think you can disable some of the transports and only use long-polling as the primary transport method

[Jordan Lance]

And how would that look in code? Cannot find any example of long polling in faye. Thats the problem just an example would help fix this.

[Aleksey V Zapparov]

For the client it's as easy as:

client.disable('websocket');

For the server:

Faye::CONNECTION_TYPES.replace %w{my fav types}

Notice, that Faye has a list of mandatory types. They are:
'long-polling', 'callback-polling' and 'in-process'. So, basically what
you would like to do is:

Faye::CONNECTION_TYPES.replace Faye::MANDATORY_CONNECTION_TYPES


--
Sincerely yours,
Aleksey V. Zapparov A.K.A. ixti
FSF Member #7118
Mobile Phone: +34 677 990 688
Homepage: http://www.ixti.net
JID: zapp...@jabber.ru

*Origin: Happy Hacking!

[James Coglan]

On 12 July 2012 15:33, Jordan Lance <voor...@gmail.com> wrote:

Yes but is this documented on how to code a long polling mechanism ?

This is something you don't need to implement, it's taken care of for you. To be more specific, Faye is an implementation of the Bayeux messaging protocol, which delivers JSON messages over various transport types including long-polling. The protocol specifies that the connection is always initiated using long-polling since all browsers support this, but the connection can then be upgraded depending on what the server says it supports and what tools are available in the current browser.

So, long-polling is just an implementation detail of Faye's messaging protocol, not something you code yourself.

[Jordan Lance]

Ok thanks that gives some clearness. Im still not sure though how to implement ( or not implement but setup ) faye so that it will work as I posted in the first message. The server should send data to the client and keep the connection open ( on a reload of the webbrowser) it should instantly resend the data if its not recieved. I think we talked about this earlier but the long polling method should take care of that, right?

Would just setting faye up to use long polling take care of it? as in the following scenario cases:

A) client recieves data ( client = user browsing webapplication written in ror )
B) client gets data send from faye but reloads just at the moment this data is send to the client, resulting in it not recieved ( broken connection ) after the page reloads has been completed the long polling would still have an open connection with faye and the data is re-send. then the connection is closed and a new connection is opened. ( the long polling )

Sorry for beeing so newbie on this Im already reading the cometD server documentation to get a better idea.

On Friday, July 13, 2012 12:35:57 PM UTC+2, James Coglan wrote:

[James Coglan]

On 13 July 2012 14:17, Jordan Lance <voor...@gmail.com> wrote:

Ok thanks that gives some clearness. Im still not sure though how to implement ( or not implement but setup ) faye so that it will work as I posted in the first message. The server should send data to the client and keep the connection open ( on a reload of the webbrowser) it should instantly resend the data if its not recieved. I think we talked about this earlier but the long polling method should take care of that, right?

Would just setting faye up to use long polling take care of it? as in the following scenario cases:

A) client recieves data ( client = user browsing webapplication written in ror )
B) client gets data send from faye but reloads just at the moment this data is send to the client, resulting in it not recieved ( broken connection ) after the page reloads has been completed the long polling would still have an open connection with faye and the data is re-send. then the connection is closed and a new connection is opened. ( the long polling )

Sorry for beeing so newbie on this Im already reading the cometD server documentation to get a better idea.

Long-polling doesn't deal with this at all. When the page is reloaded, all network connections of any type that the JavaScript runtime has open are closed. If the server has just sent a long-poll response just when the page reloads, the client will not receive the data but the server will also not re-send it, because that message has already left the server.

What you have to bear in mind is Faye (and the underlying transport mechanisms) are just a way of sending messages between client and server. It does not provide delivery guarantees, and no particular transport mechanism can provide such a guarantee on its own. This is something you need to build on top, by keeping a copy of each message on the server, making the client send an 'acknowledge' message each time it receives something, then deleting the message queued on the server when the server receives this acknowledgement (ack). If no ack is received after a certain amount of time, the server re-sends the message.

Faye is just a means of transmitting these messages in an abstract manner. Different apps tend to have different delivery constraints, which is why Faye (and the Bayeux protocol) doesn't attempt to solve this for you. You're better off, on the web, recognizing that messages can be lost, delayed etc and making sure you code your data transfer logic to make sure the app does something consistent with each message it gets.