Clarification on timeout on faye node server side

[Pratheep Velicherla]

Hi,

I am pretty new to faye. 

we are planning to using faye node server as our notification system. So, far its great, but When I watch the websocket inspector in crome, I can see lots of messages like this 

"channel":"/meta/connect","successful":true,"advice":{"reconnect":"retry","interval":0,"timeout":60000}}

Is it because of timeout value in server side? 

I have timeout value as 60s. 

Right after that I can see [{"channel":"/meta/connect","clientId":"randomnumber","connectionType":"websocket","id":"5"}]. 

I went through the docs but I didn't got enough information. 

If I increase this timeout value in server will it give use some more performance again?

More over we are having secure check on handshake. 

Thanks,

Pratheepv

[James Coglan]

On 26 January 2014 16:31, Pratheep Velicherla <pratheep....@gmail.com> wrote:

Right after that I can see [{"channel":"/meta/connect","clientId":"randomnumber","connectionType":"websocket","id":"5"}]. 

I went through the docs but I didn't got enough information. 

The Bayeux protocol spec explains this: http://svn.cometd.org/trunk/bayeux/bayeux.html. In non-socket transports, this message is sent to poll for new messages, and those messages are delivered along with the response. As soon as the response is received and new request is made.

For WebSocket, messages are delivered independently of this mechanism but it's still used to keep the client session alive.

 

If I increase this timeout value in server will it give use some more performance again?

No, and it will make the client take longer to detect certain kinds of errors.

 

More over we are having secure check on handshake.

These messages are not handshakes. Handshaking happens once per connection, and then connect messages are sent periodically.

[Pratheep Velicherla]

Thanks for the clarification.

--
You received this message because you are subscribed to the Google Groups "Faye users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to faye-users+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Paul Banks]

Hi James, 

I'm also trying to figure this out.

What is the rationale for still requiring timeout's and connect handshakes on WebSocket connections?

You said "No, and it will make the client take longer to detect certain kinds of errors." but that only seems true for non-websocket transports since websocket one sends periodic ping already.

It seems slightly redundant having client timeout and re-send connect message every 45 seconds or so for Websocket when it is already sending ping to keep socket alive through proxies etc. and detect failure.

The bayeux protocol as linked does not have a specification for web sockets only for long polling, the ping part is certainly additional to the base protocol too.

So am I missing something? Is the timeout/reconnect a way of touching the session state in engine to prevent it being GCed? If so why can't simple empty ping message be used for that instead? And what is the purpose of ping messages in this case given that logn-polling can't use them so you already must ensure timeout is less than any intermediate proxy/load balancer timeouts for long-polling to work?

Thanks for your help, sorry for digging up older thread but I reasoned that it would be better for future searchers to have the discussion all in one place.

Thanks again

Paul

[James Coglan]

On 28 October 2014 13:29, Paul Banks <ban...@gmail.com> wrote:

What is the rationale for still requiring timeout's and connect handshakes on WebSocket connections?

In the first instance, the client has to identify itself. If it connects a WebSocket and sends no /meta/connect message, the server has no idea which client it is, and won't route messages to it. So it needs to send at least one such message to get the server to recognise it.

After that, it's a question of keeping the client's session alive -- if a client does not send /meta/connect messages periodically when the server expects them, the server will time the client's session out. Before we had WebSockets had to everything with requests, this was the only way for the client to let the server know it's still alive.

Even now we have WebSocket, it's easier to keep that mechanism since it means the client can perform the same protocol no matter which transport is in use, so it keeps the message protocol and the transport layer nicely decoupled. If we relied on transport-specific keep-alive mechanisms, then things would get messier, especially in cases there are messages in flight on multiple transports at the same time, as is the case during transport negotiation.

It also means that extensions, which work at the protocol layer, rather than the transport layer, see a consistent view of the protocol no matter which transport is in use, which is important to keep the network layer's details leaking into people's apps.

You said "No, and it will make the client take longer to detect certain kinds of errors." but that only seems true for non-websocket transports since websocket one sends periodic ping already.

There's no API in the browser for WebSocket to send pings and detect pongs, even though it's in the protocol. So this is not actually usable as a mechanism. The Faye client does not send WebSocket pings, so I'm not sure what you're referring to here.

Also, if we used WebSocket pings then we would be making assumptions about the construction of the server: just because its HTTP/WebSocket endpoint is responding, that does not mean the Bayeux service that's behind it is working correctly. To detect a connection with the Bayeux server, we really want to interact with that, not just ping the transport layer and assume that means everything is fine.

If you want to check a website is up, you send it an actual request, you don't just open a TCP socket.

It seems slightly redundant having client timeout and re-send connect message every 45 seconds or so for Websocket when it is already sending ping to keep socket alive through proxies etc. and detect failure.

This is really not a lot of overhead considering how much simplicity it allows clients and servers to maintain by keeping the protocol and transport layers decoupled, and for making sure the peers on either end are really working.

 

The bayeux protocol as linked does not have a specification for web sockets only for long polling, the ping part is certainly additional to the base protocol too.

So am I missing something? Is the timeout/reconnect a way of touching the session state in engine to prevent it being GCed? If so why can't simple empty ping message be used for that instead?

Did my previous answers cover this? Yes, the client sending /meta/connect stops servers from GC-ing the session. Remember that the Faye client must interoperate with other Bayeux servers, so it has to abide by the spec and it can't introduce its own custom keep-alive methods outside of the protocol as defined.

 

And what is the purpose of ping messages in this case given that logn-polling can't use them so you already must ensure timeout is less than any intermediate proxy/load balancer timeouts for long-polling to work?

I'm not sure what you mean here about long-polling not being able to use pings, partly because I don't know what you're referring to when you've been saying 'ping'. Can you clarify what you mean? 

[Paul Banks]

Thanks James,

Your answer is helpful and for the most part I'd drawn the same conclusions from looking at how faye is designed and the protocol.

If it helps, I think part of initial confusion was that I didn't know the history and expected any recent "real time" protocol to be optimised for websockets. Discovering bayeux actually predates and makes no mention of websockets specifically explains a lot about the protocol design and of course it makes total sense that you need to maintain same protocol regardless of transport.

I think if one cares enough about it, it's possible to design a protocol that can use both websockets and long polling fallback and still be better optimised for both use-cases, but of course you will probably end up with something much less flexible and more opinionated if you do so.

That said I've looked at engine.io and SockJS too and both of those are the reverse - they try to emulate websockets on fallback transports even to the point where a long-polling connection with engine.io is terminated not by the ping timeout and since it has to reply with a PONG it sends POST request for that and then re-opens long-poll. i.e. totally sub-optimal for long-polling clients due to their goal of providing as close to the websocket API as possible.

FWIW, my current use case is pretty specialised (push only to fixed and known-in advance number of channels per page on a website) so most of these generic solutions are inevitably sub-optimal and most of the complexity in the code is to handle edge cases I just don't care about.

Back to Faye...

The ping part I'm still confused about although I realise it's pretty trivial in practice and not a major performance concern, I just don't see why it was ever built...

> I'm not sure what you mean here about long-polling not being able to use pings, partly because I don't know what you're referring to when you've been saying 'ping'. Can you clarify what you mean? 

To be clear I'm referring to the [] ping packets that server periodically sends client, controlled by the 'ping' option passed to server (or set to timeout/2).

I assumed that this would only apply to websocket transport since long polls must be configured to be within proxy timeouts anyway and sending ping effectively just means you are shortening the poll length. That does appear to be the case with Faye - server sent pings only seem to happen for websocket and event source transports...

I also initially assumed that the whole purpose of ping was to keep WebSockets alive through proxy idle timeouts and then wouldn't need any further idle communication which was the real root of my question above. The protocol fidelity issue answers that.

So when I realised that WebSocket clients DO respect timeout and resend /meta/connect just as often as long-poll transports poll, I'm now confused why server ping was ever added for websockets? It doesn't appear to be part of bayeux protocol which only dealt with polling transports so needed no explicit keepalive mechanism. For a websocket you are already sending /meta/connect every timeout seconds and surely timeout must be set low enough to avoid idle connection killing proxies/load balancers already otherwise long polls just won't work.

So given that in both cases you are already doing a full round trip every timeout seconds and that timeout must be lower than the idle timeout of your intermediate proxies (or at least sane ones or ones you control) then why bother with server sending ping at all?

I understand server can't know if client dropped connection without trying to send periodically, but it seems timeout period and connect response is still perfectly adequate there.

Anyway as I said it's not a big deal - ping traffic is negligible, I'm just confused why the extra code to support pinging was added given that it apparently adds nothing. It's very possible that I overlooked something in my analysis of course ;)

Thanks for help

Paul

[James Coglan]

On 11 November 2014 08:41, Paul Banks <ban...@gmail.com> wrote:

The ping part I'm still confused about although I realise it's pretty trivial in practice and not a major performance concern, I just don't see why it was ever built...

> I'm not sure what you mean here about long-polling not being able to use pings, partly because I don't know what you're referring to when you've been saying 'ping'. Can you clarify what you mean? 

To be clear I'm referring to the [] ping packets that server periodically sends client, controlled by the 'ping' option passed to server (or set to timeout/2).

I assumed that this would only apply to websocket transport since long polls must be configured to be within proxy timeouts anyway and sending ping effectively just means you are shortening the poll length. That does appear to be the case with Faye - server sent pings only seem to happen for websocket and event source transports...

I also initially assumed that the whole purpose of ping was to keep WebSockets alive through proxy idle timeouts and then wouldn't need any further idle communication which was the real root of my question above. The protocol fidelity issue answers that.

So when I realised that WebSocket clients DO respect timeout and resend /meta/connect just as often as long-poll transports poll, I'm now confused why server ping was ever added for websockets? It doesn't appear to be part of bayeux protocol which only dealt with polling transports so needed no explicit keepalive mechanism. For a websocket you are already sending /meta/connect every timeout seconds and surely timeout must be set low enough to avoid idle connection killing proxies/load balancers already otherwise long polls just won't work.

So given that in both cases you are already doing a full round trip every timeout seconds and that timeout must be lower than the idle timeout of your intermediate proxies (or at least sane ones or ones you control) then why bother with server sending ping at all?

For some deployments, people were finding that the /meta/connect timeout was not frequent enough for some proxies, which would trigger idle timeouts and close the connection. Faye actually implements measures against this on both sides of the connection -- the client and server don't assume they're talking to a Faye peer, they could be talking to any Bayeux implementation.

The server sends actual WebSocket ping frames -- apologies for the confusion earlier, the client doesn't send these but the server does. These ping frames are never exposed to client-side JS and are handled internally by the browser's WebSocket implementation, so they won't affect any Bayeux client implementation:

https://github.com/faye/faye/blob/345f76ea7734edfcad10a92f50bf1bca1a00961a/javascript/adapters/node_adapter.js#L173

Since the server can send WebSocket pings, it does so and uses the user-supplied 'ping' setting for this.

On the client side, there is no JS API for sending WebSocket pings, so the client has to send some actual data over the wire. It sends the empty message list [] since the server will simply ignore it. The best information the client has to go on for sending these pings is 'something more frequent than the /meta/connect timeout'; the client could take a user-supplied 'ping' value but since the client has to be told by the server what the server's timeout is, it makes more sense to use that.

https://github.com/faye/faye/blob/345f76ea7734edfcad10a92f50bf1bca1a00961a/javascript/transport/web_socket.js#L114 

[Paul Banks]

> For some deployments, people were finding that the /meta/connect timeout was not frequent enough for some proxies

Ah interesting.

My assumption had been that if proxies can't handle websockets that are idle for timeout seconds then they would also fail for longpolls with same timeout. Which means if you have issues with proxies and need 25 second ping, that would imply long polls would also need to be reduced to 25 seconds hence timeout was the only useful parameter and pings are redundant.

From what you are saying it sounds like that might not be the case? You had people finding proxies timing out web sockets but not long polls of same length? I've heard of mysterious behavior with web sockets and some corporate profits etc do maybe that is related.

That would explain my confusion, but I'm intrigued why any proxy would have different idle timeout for the two connection types.

Thanks for your help again.

Paul

[Кирилл Ефимов]

I am also confused about "ping" option. I understand differences in behavior of "ping" and "timeout", but don't understand why transport-dependent option "ping" is in public API.

Is "ping" really redundant in real project?

Thanks.