The list of "rakes" of websocket implementation to the client web resources of site designer

Websocket'y useful constant duplex connection backend server client browser - it is a strong bridge between the service and visitors, which is convenient to freely transport data streams in both directions.

As a result of websocket implementation, our project was able to change the display of pages in the browser at its own discretion throughout the client session and have feedback in real time.

In the course of building the whole technological chain, we easily stepped over problems with browsers that only occasionally do not support either the websockets themselves, or their emulation via flash.
')
However, when it came to field trials, we discovered a lot of problems with ISPs trying to save traffic at the expense of their customers in every imaginable and unthinkable way. Read about these and other "rakes" of full-fledged websocket's combat implementation under the cut.

For example, in the Moscow office of our company, the ISP proxy server (the largest in Moscow) cuts out the websocket handshake headers. Thus, 80% of our efforts were spent on resolving these problems in a peaceful way.

But there is some good news: a bunch of technologies built is already in beta testing now. We are learning to control all the links in the process chain from falling out - this is a question of administration, at which we tighten all the nuts. The bridge is induced, stretched out and waits for the first visitors.

Here is a brief chronicle of problem solving during the implementation phase.

• Mojolicious cannot work in production using Mojo :: Server :: Daemon: unstable behavior under heavy loads (hangs, memory leaks, loss of connections). But it feels great on Mojo :: Server :: Hypnotoad.
• Safary on iPhone (iPad, iPod) uses WebSocket76, which Mojolicious no longer supports. The solution was the MojoX :: Transaction :: WebSocket76 module we wrote.
• The tricks of ISP with client traffic defeated the SockJS.org solution, which emulates websocket's by various transports: xhr-streaming, xdr-streaming, iframe-eventource, iframe-htmlfile, xhr-polling, xdr-polling, iframe-xhr-polling, jrsp- polling.
• SockJS with Mojolicious is connected via doped SockJS-Tornado. I had to finish using the python module WebSocket for it, asynchronous work not only on the external channel, but also on the internal one.
• Especially for our “favorite” ISP, the websocket transport works on port 80 (since all other ports are not protected from ISP blocking). Allocated ip-shniki and subdomains for client sites.
• Session data is stored in MemCache.
• JSON RPC 2.0 + HTML :: FormHandler + DBIx :: Class was chosen as the transport of communication. All requests to the server are full forms, the answer to which can come errors. Their multilingualism is implemented via gettext.
• As separate “rakes” (albeit minor ones), it is worth mentioning the need to process Russian-language domains at the js level using punycode.
• We really ping client browsers. We have pings, in response to which we accept pongs.

The resulting scheme provides 100% coverage of all users. You can watch the implementation results on any sites built on setup.ru, - in beta testing websocket'y are used for feedback forms (“question” ear) and an online store basket.

Related Links:

1. Wikipedia about web sockets
2. Project mojolicious
3. Project SockJS
4. Perl module MojoX :: Transaction :: WebSocket76
5. Perl module Mojo :: Server :: Hypnotoad
6. Python module SockJS-Tornado
7. Python module WebSocket
8. Site Builder Setup.ru