On 10/12/12 9:21 AM, Waqas Hussain wrote: > On Fri, Oct 12, 2012 at 11:23 AM, Michael Weibel > <[email protected]> wrote: >> Hi, >> >>> >>> How would we handle fallback? I suppose that's a good topic to discuss >>> in the meeting, but it would also be good to know what our options are >>> (e.g., how do you discover the WebSocket endpoint in the first place >>> and how do you discover that you can fall back to BOSH?). XEP-0156 >>> might be relevant here. >> >> we're currently doing this manually, i.e. we're giving our javascript client >> both endpoints and this one looks if WebSockets are available in the browser. >> When WebSockets are available it connects to the WebSockets endpoint. If he >> can't connect successfully after some time it will fallback to BOSH. >> >> This works not too bad although it could be improved more. >> >> What I'm wondering is: Could it be possible that you first connect to BOSH >> and afterwards check if Websockets is available and somehow upgrade the >> current connection? >> This would speed up the whole process I guess while being still quite stable >> and reliable. >> > > Or if you care about user experience more than server load, just > initiate both connections, and pick the first one to succeed :)
Right, that's the "happy eyeballs" approach. https://datatracker.ietf.org/doc/rfc6555/ Peter -- Peter Saint-Andre https://stpeter.im/
