Comments on: Elko III: Scale Differently

By: Chip

Chip — Tue, 07 Sep 2010 04:40:48 +0000

Victor, that’s a very reasonable question. There is some similarity, and to the extent that one’s application entails a single client’s interaction with it’s own autistic session state, they are basically the same thing. However, there are a couple of points of differentiation that matter to a broader range of applications. The most important is that multiple clients can be readily routed to a common session context containing shared state that is relevant to all of them. The canonical example is a real-time, multiplayer game, but you might also consider auctions, shared graphical workspaces, or live online slide presentations — anything where lively shared data that spans multiple client sessions would be of value. Another notable differentiator, less profound but still useful pragmatically, is the shift in perspective that arises when you regard the client-server connection as a channel to a process rather than to a purely reactive object. That’s a little abstract, so let me dig into it a bit more: a conventional web server is designed to act by responding to each HTTP request as it is delivered. Elko does that also, but since it decouples the HTTP request/response handshake from the application message protocol, it can also initiate communication to the client asynchronously. Timers and other processes can run autonomously on the server and then send messages to the client when they feel the need to do so. For example, an auction application might close bidding after the passage of sufficient time with no new bids submitted — and then notify everyone participating in the auction that this has happened. All of that can (and has been) done with a conventional web server also, but it cuts against the grain and requires jumping through a few hoops, whereas Elko does this natively.

By: JavaScript and HTTP

JavaScript and HTTP — Tue, 07 Sep 2010 02:42:32 +0000

[...] client to a given server that maintains state in memory. In addition to Chip Morningstar’s post on Elko, see JSON Messaging Over HTTP that explains what happens at the HTTP level. The client [...]

By: Victor Doss

Victor Doss — Fri, 03 Sep 2010 19:35:30 +0000

Maybe I am missing something completely (which is most likely), but what is the difference between this and a traditional web architectures with sticky session turned on ? When you say “client”, is that the browser client ? or both browser and server which are clients to this context framework ?

ps: The build up was great in the part II, but this part was a total let down (atleast for thick heads like me)

By: Chip

Chip — Fri, 11 Sep 2009 21:48:02 +0000

All the Directors’ data structures are non-persistent. When Context Servers come up they notify the Directors of their availability to provide services. They then keep the Directors informed of their ongoing availability and load status. In addition, there’s a protocol whereby the Directors keep each other updated about their own statuses, so that they can also go up and down, and so that new Directors can be added to the cluster dynamically.

There’s also a more complex configuration, not described in my post but covered in some of the docs in the release package (though I will confess that here things could benefit from more documentation love), where there’s an additional kind of server called a Broker that keeps track of a heterogeneous collection of Elko servers and the various services they offer to other servers in the farm. The Broker acts as a kind of configuration manager, so that each server only needs to know one point of contact to get wired up with everybody else.

By: Chris Lauwers

Chris Lauwers — Fri, 11 Sep 2009 17:33:01 +0000

Yes, I should have been more specific: my question has to do with replicating state between multiple Directors. Do you use a shared database for this?

By: Chip Morningstar

Chip Morningstar — Fri, 11 Sep 2009 16:19:38 +0000

Chris, I guess I implied the answer but I should have been clearer about that. You make the Director fault tolerant through simple redundancy — just set up multiple Directors. At State Software, our standard configuration was 2 Directors, and this was for fault tolerance rather than scaling. You can have as many Directors as you like, though more than 2 or 3 is probably overkill. Client traffic to the multiple Directors is then routed using rotating DNS or a VIP, just as you would with a regular web server cluster.

By: Chris Lauwers

Chris Lauwers — Thu, 10 Sep 2009 21:04:28 +0000

Chip,

in addition to scalability, the other argument often used for “traditional” web architectures is built-in redundancy and fault-tolerance. In the Elko architecture, how do you make the Director fault-tolerant?