Thursday, September 29, 2016

WebSockets

WebSockets

A WebSocket is a standard protocol for two-way data transfer between a client and server. The WebSockets protocol does not run over HTTP, instead it is a separate implementation on top of TCP.

Why use WebSockets?

A WebSocket connection allows full-duplex communication between a client and server so that either side can push data to the other through an established connection. The reason why WebSockets, along with the related technologies of Server-sent Events (SSE) and WebRTC data channels, are important is that HTTP is not meant for keeping open a connection for the server to frequently push data to a web browser. Previously, most web applications would implement long polling via frequent Asynchronous JavaScript and XML (AJAX) requests as shown in the below diagram.
Long polling via AJAX is incredibly inefficient for some applications.
Server push is more efficient and scalable than long polling because the web browser does not have to constantly ask for updates through a stream of AJAX requests.
WebSockets are more efficient than long polling for server sent updates.
While the above diagram shows a server pushing data to the client, WebSockets is a full-duplex connection so the client can also push data to the server as shown in the diagram below.
WebSockets also allow client push in addition to server pushed updates.
The WebSockets approach for server- and client-pushed updates works well for certain categories of web applications such as chat room, which is why that's often an example application for a WebSocket library.

Implementing WebSockets

Both the web browser and the server must implement the WebSockets protocol to establish and maintain the connection. There are important implications for servers since WebSockets connections are long lived, unlike typical HTTP connections.
A multi-threaded or multi-process based server cannot scale appropriately for WebSockets because it is designed to open a connection, handle a request as quickly as possible and then close the connection. An asynchronous server such as Tornado or Green Unicorn monkey patched with gevent is necessary for any practical WebSockets server-side implementation.
On the client side, it is not necessary to use a JavaScript library for WebSockets. Web browsers that implement WebSockets will expose all necessary client-side functionality through the WebSockets object.
However, a JavaScript wrapper library can make a developer's life easier by implementing graceful degradation (often falling back to long-polling when WebSockets are not supported) and by providing a wrapper around browser-specific WebSocket quirks. Examples of JavaScript client libraries and Python implementations are found below.

JavaScript client libraries

  • Socket.io's client side JavaScript library can be used to connect to a server side WebSockets implementation.
  • web-socket-js is a Flash-based client-side WebSockets implementation.

Python implementations

  • Autobahn uses Twisted or asyncio to implement the WebSockets protocol.
  • Crossbar.io builds upon Autobahn and includes a separate server for handling the WebSockets connections if desired by the web app developer.

Nginx WebSocket proxying

Nginx officially supports WebSocket proxying as of version 1.3. However, you have to configure the Upgrade and Connection headers to ensure requests are passed through Nginx to your WSGI server. It can be tricky to set this up the first time.
Here are the configuration settings I use in my Nginx file as part of my WebSockets proxy.
# this is where my WSGI server sits answering only on localhost
# usually this is Gunicorn monkey patched with gevent
upstream app_server_wsgiapp {
  server localhost:5000 fail_timeout=0;
}

server {

  # typical web server configuration goes here

  # this section is specific to the WebSockets proxying
  location /socket.io {
    proxy_pass http://app_server_wsgiapp/socket.io;
    proxy_redirect off;

    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_read_timeout 600;
  }
}
Note if you run into any issues with the above example configuration you'll want to scope out the official HTTP proxy module documentation.
The following resources are also helpful for setting up the configuration properly.

Open source Python examples with WebSockets

  • The python-websockets-example contains code to create a simple web application that provides WebSockets using Flask, Flask-SocketIO and gevent.
  • The Flask-SocketIO project has a chat web application that demos sending server generated events as well as input from users via a text box input on a form.

General WebSockets resources

  • The official W3C candidate draft for WebSockets API and the working draft for WebSockets are good reference material but can be tough for those new to the WebSockets concepts. I recommend reading the working draft after looking through some of the more beginner-friendly resources list below.
  • WebSockets 101 by Armin Ronacher provides a detailed assessment of the subpar state of HTTP proxying in regards to WebSockets. He also discusses the complexities of the WebSockets protocol including the packet implementation.
  • The "Can I Use?" website has a handy WebSockets reference chart for which web browsers and specific versions support WebSockets.
  • Mozilla's Developer Resources for WebSockets is a good place to find documentation and tools for developing with WebSockets.
  • WebSockets from Scratch gives a nice overview of the protocol then shows how the lower-level pieces work with WebSockets, which are often a black box to developers who only use libraries like Socket.IO.
  • websocketd is a WebSockets server aiming to be the "CGI of WebSockets". Worth a look.

A decentralized vehicle monitoring and communication pattern design

Recently, V2X or telematics becomes a very hot topic. It's also a very interesting point to dig into the topic, how to design a V2X communication pattern.

People say that, what is so called telematics is embedded your iPhone in your car. So the this inspires me, how the MNOs track the mobile phone's status? How MNOs detect if an iPhone is online or not?

So the first question come into my mind, how the IP addresses are allocated to the mobile devices?

Then I searched google for some resources I found out, for current dedicated GSN implementation for OEM, all the resources in fact are centrally managed, it's really hard to distinguish the geo differences.

Then it becomes very interesting that the vehicle communication design should follow cellular communications pattern, then something came to my mind recently here are some results.