Transport negotiation

[flowersinthesand]

https://groups.google.com/d/msg/portal_project/guBmhMXZFK0/Hfm7gcOjF-YJ

[ghost]

Here's what I'd imagine would be the ideal use case from the user code perspective.

The user code specifies {transports: 'auto'} option when opening a new connection, and it's then the library task to deal with transport negotiation. Therefore when the socket transitions to 'connected' state, client code can simply start message exchange.

The library would negotiate optimal transport according to an algorithm like that.

1. Construct a list of transports sorted by priority/"quality".

• If the browser is a known browser/version, use built-in list. For example, for FF v.10+ it would be [ws, streamxhr/sse, longpoll], for IE8 - [streamiframe, longpolljsonp], for IE7 - [longpolljsonp], etc.
• else test for the presence of ws and xhr and depending on the results, use one of the lists: [ws, streamxhr, longpolljsonp], or [streamxhr, longpolljsonp], or just [longpolljsonp]
• For each transport in the list do the following:
• attempt to connect using this transport
• if the transport is one of longpoll transport, keep it (no more transports to fall back to)
• else if connection fails immediately (i.e., without first firing 'connected'), discard this transport and try next one
• else if connection drops within a specified interval (1-2-5 seconds), try once more, and if the connection drops again within that same interval, discard the transport and try next one
• else keep connection

Something like this will work for the vast majority of use cases, and it doesn't require any changes in JS API (apart from a new possible parameter to portal.open()), nor any changes on the server. And the remaining use cases could be covered by client code. For example, client code could always start with a longpoll transport for fastest possible startup, then attempt to open a ws connection and if it succeeds and persists for at least several seconds, reconnect portal library to the ws transport.