The list of "rakes" websocket'ov implementation on client web resources site builder

Websockets are useful for the constant duplex connection of the backend server to the client’s browser - this is a strong bridge between the service and visitors, which makes it convenient to freely transport data flows in both directions.

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

During the construction of the entire technological chain, we easily stepped over problems with browsers that only occasionally did not support either websockets themselves or their emulation via flash.

However, when it came to field trials, there were a lot of problems with ISPs, in every imaginable and inconceivable way, trying to save traffic at the expense of their customers. Read about these and other "rakes" of full-fledged combat deployment of websocket’s under a cat.

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

But there is good news: the bundled technology bundle is now in beta testing. We learn to control all the links of the technological chain from falling out - this is a matter of administration, on which we tighten the nuts more and more tightly. The bridge is pointed, pulled into the string and is waiting for the first visitors.

Here is a brief chronicle of problem solving at the implementation stage.

  • Mojolicious cannot work in production using Mojo :: Server :: Daemon: unstable behavior under heavy loads (freezes, memory leaks, lost 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 that we wrote.
  • The ISP tricks with client traffic were won by the SockJS.org solution emulating websockets with various transports: xhr-streaming, xdr-streaming, iframe-eventsource, iframe-htmlfile, xhr-polling, xdr-polling, iframe-xhr-polling, jsonp- polling.
  • SockJS with Mojolicious is connected through the dopped SockJS-Tornado. I had to finish using the python module WebSocket to him asynchronous work not only on the external channel, but also on the internal.
  • Especially for our “beloved” ISPs, websocket transport works on port 80 (since all other ports are not protected from ISP blocking in any way). Allocated ip-shniki and subdomains for client sites.
  • Session data is stored in MemCache.
  • Communication transport selected JSON RPC 2.0 + HTML :: FormHandler + DBIx :: Class. All server requests are full-fledged forms, the answer to which may be errors. Their multilingualism is implemented through gettext.
  • As separate "rake" (though insignificant) it is worth mentioning the need to process at the js level Russian-language domains using punycode.
  • We really ping client browsers. We have pings, in response to which we accept pongs.


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

Related links:
  1. Wikipedia about websockets
  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