2

Situation

We're using socket.io for mobile-server communications. Since we can't force-upgrade users' devices, if we want to upgrade to version 1 (non-back-compatible), we have to handle both versions on the server for a while.

Question

What are the options?

My current favourite is to wrap both the old version and the new version in a multiplexer. It detects the version of the incoming request based on headers and query parameters and thereby knows which functions to invoke.

Another (shittier) option is to wrap the new version in a module that can translate the old version of the protocol into the new version (and back again) when necessary. This suffers from a serious drawback. It would be time-consuming and uncertain work to ensure I've properly determined and handled all the tiny differences. Some differences might take some serious massaging.

(In case you're curious or it's helpful to know, we're doing this in Go.)

sheac
  • 592
  • 5
  • 12
  • I wonder if you could run the new version on a different port so you'd have both versions running, each on their own port. New clients would use the new version on the new port. – jfriend00 Apr 14 '15 at 03:26
  • 1
    To me, the cleanest solution would be to detect the version header in a middleware func, and then pass the r, w to the appropriate handler. You could use internal packages to contain the apiv1 and apiv2 logic, include those in your main goroutine, and have the endpoint logic there. – Momer Apr 14 '15 at 13:37
  • @jfriend00 That might be tricky, since websockets require dedicated ports as far as I know. – sheac Apr 14 '15 at 15:35
  • @Momer I like your thinking. Thanks for putting it in terms of Go's net/http r/w for better understanding. – sheac Apr 14 '15 at 15:35
  • webSockets can run on any port. The normal implementation is that they share port 80 with http. This works because a webSocket connection starts with an http request that is then "upgraded" to the webSocket protocol if both sides agree. You could certainly have two versions of socket.io running and listening on different ports. You'd probably have to rename one of the modules (or load them from different locations) and perhaps do something with NPM so it doesn't get confused about versioning and upgrades. But, once loaded I see no reason why this couldn't work. – jfriend00 Apr 14 '15 at 22:05

3 Answers3

2

It appears that you could run two separate versions of socket.io on the server. Since the two versions don't have unique module filenames you would probably need to load one version from a different path. And, then obviously when loading the modules and initializing them you'd assign them to differently named variables. For example:

var io_old = require('old/socket.io');
var io = require('socket.io);

Once you have the two versions loaded on the server, I think there are two different approaches for how they could be run.

1) Use a different port for each version. The older version would use the default port 80 (no configuration change required for that) which is shared with the node.js web server. The newer version would be run on a different port (say port 3000). You would then initialize each version of socket.io to its own port. Your newer version clients would then connect to the the port the newer version was running on.

For the old socket.io server running on port 80, you would use whatever initialization you already have which probably hooks into your existing http server.

For the new socket.io server running on some other port, you would initialize it separately like this:

var io_old = require('old/socket.io')(server);
var io = require('socket.io')(3000);

Then, in the new version client, you would specify port 3000 when connecting.

var socket = io("http://yourdomain.com:3000");

2) Use a different HTTP request path for each version. By default, each socket.io connection starts with an HTTP request that looks like this: http://yourdomain.com/socket.io?EIO=xx&transport=xxx?t=xxx. But, the /socket.io portion of that request is configurable and two separate versions of socket.io could each be using a different path name. On the server, the .listen() method that starts socket.io listening takes an optional options object which can be configured with a custom path as in path: "/socket.io-v2". And similarly, the .connect() method in the client also accepts that options object. It's kind of hard to find the documentation for this option because it's actually an engine.io option (which socket.io uses), but socket.io passes the options through to engine.io.

I have not tried either of these myself, but I've studied how socket.io connections are initiated from client and server and it looks like the underlying engine supports this capability and I can see no reason why it should not work.

Here's how you'd change the path on the server:

var io = require('socket.io')(server, {path: "/socket.io.v1"});

Then, in the client code for the new version, you'd connect like this:

var socket = io({path: "/socket.io.v1"});

This would then result in the initial connection request being made to an HTTP URL like this:

http://yourdomain.com/socket.io.v1?EIO=xx&transport=xxx?t=xxx

Which would be handled by a different request handler on your HTTP server, thus separating the two version.

FYI, it is also possible that the EIO=3 query parameter in the socket.io connection URL is actually an engine.io version number and that can also be used to discern client version and "do the right thing" based on that value. I have not found any documentation on how that works and could not even find where that query parameter was looked at in the engine.io or socket.io source code so that would take more investigation as a another possibility.

jfriend00
  • 683,504
  • 96
  • 985
  • 979
0

I don't really have an immediate solution for this, but I have some kind of advice. I guess you could use it to save a lot of time.

  • first of all Im working in a startup which uses socketIo for almost
    everything
  • We knew that this problem would happen so our initial design was to
    make everything pluggable which means that we can swap out socketio for
    sockjs and it will still work.
  • The way its done is by defining the common set of APIs which rarely change
    in a system. We call it managers. The managers can just expose the API which the rest of the devs need to use without messing up anything. It speeds up a lot.
  • The manager implementation changes in the background but still the APIs are the same, so the engineers working on the core can confidently make changes.
  • Seems like you have a tight dependency in your code. Or may be not. I'm not so sure. Try following this principle if you haven't.
Vijay Britto
  • 41
  • 7
0

We're going to go the route of keeping both the 0.9.x version and the current version as separate libraries on the server. Eventually, when the pool of clients has more-or-less all updated, we'll just pull the plug on the 0.9.x version.

The way we'll manage the two versions is by wrapping the socket.io services in a package that will determine which wrapped socket.io version to pass the request off to. This determination will depend on features of the request, such as custom headers (that can be added to the newer clients) as well as query parameters and other headers utilized exclusively by one version or the other.

Since we're using Go, there's so far no universally agreed upon way to manage dependencies, let alone a way that can respect version differences. Assuming the back-compat branch of the repo wasn't broken (which it is), we'd have two options. The first would be to fork the repo and make the back-compat version the master. We'd then import it as if it had nothing to do with the other one. The second option would be to use gopkg.in to pretend the separate branches were separate repos.

In either event, we could import the two branches/repos like so

import (
    socketioV0 "github.com/path/to/older/version"
    socketioV1 "github.com/path/to/current/version"
)

And then refer to them in the code using their import names socketioV0 and socketioV1.

sheac
  • 592
  • 5
  • 12