So, after my first article I decided to ask Mike Rettig what I’d missed. I have to admit to still not having had time to play with it myself,* however his reply was sufficiently interesting I asked to be allowed to share it. He was kind enough to permit this. There’s no explicit quoting here, but pretty much the credit for the pain points section is owing to Mike. Any errors are my own.
Publish/Subcribe Pain Points
In the original article I stated that client and server were identical. This isn’t really true. In particular, a server is an acceptor and a client is an initiator, in standard TCP style. Although both can publish and subscribe, the presence of topics in the protocol allows for server side filtering. To make all of this easier to understand, imagine you’re writing a simple application that prints up the last trade in a particular list of stocks. In classic pub/sub as ZeroMQ implements, you’d connect up to a stream that published every trade as it went down. This would mean that you were receiving many updates in which your client had no interest. You’re flooding the network with stuff that doesn’t matter, and usually your network is your most limited resource (certainly, very few have to worry about processing power and storage anymore…). Using the topic, the server can be made aware of the necessary filtering that needs to occur.
This brings us to the next strength of Jetlang Remoting that I missed, probably because I only read the protocol and not the code. When you subscribe, the server receives an event telling you this has occurred. This is actually really significant. Let’s return to our example application. Let’s say we’re interested in the trades of some obscure stock, call it Recondite Inc. Now, Recondite is an extremely illiquid and only trades once an hour. In the classic model, you will subscribe and only get told about the stock when the next trade occurs. Pretty much everyone regards this as part and parcel of the way pub/sub works and the way around it is fairly well understood: you just get the current state via an RPC first. However, with the Jetlang model, the server is not only aware of what interests you, the server is aware of when you began. Therefore it can publish the initial state through the topic.
These aren’t obscure points. Most systems I’ve worked with that involved any form a real-time data distribution encountered both of those pain points.
The last point that Mike made concerns versioning. The topic nature of subscriptions makes it relatively easy to identify the version of the client. In turn this enables the server to filter messages that it knows the client can’t handle. Achieving this without server-side filtering is possible, but only by throwing ports at the problem.
Complex Subscriptions
Lastly, I made a point last time that topics could have been made byte arrays, for complex subscription, but in practice the fact that every reply contains the topic suggests you’ll want to keep the topic small. An alternative, but more complex arrangement, would be for subscriptions to return a subscription ID first and then send data messages with the subscription ID. Once you recognize that model, you can see that you could set up such topics using an RPC call first. Jetlang therefore provides the flexibility to do complex subscriptions without requiring every program to implement code for it.
*I’m spending most of my time with client side UI and backbone.js at the moment, of which more another time.
Colour Coding 