Websockets Server with Fault-Tolerance and Durable Message Store

I am starting to experiment with websockets.

Does anyone know of a websockets server (open source or paid) that provides a durable store of the websocket "channel"? All of the examples that I have found do not address durability -- if a websockets server goes down, all "channel" data is lost.

Services such as Pusher do not really discuss whether they address the durability issue (and I have not received a response from tech support yet).

Happy to roll my own, but would rather not reinvent the wheel.

EDIT:

I'm not looking for websockets 101 information. That is readily available and understood.

I'm looking for a server (open source or paid) that supports websockets and has a durable store for the websocket data so that, in the event that a server fails, a new server can take over where the original one left off.

Two main purposes:

1. support failover scenarios contemplated by the websockets Network Working Group https://datatracker.ietf.org/doc/html/draft-ibc-websocket-dns-srv-02#section-5.1 (most importantly so that missed messages are sent when a client connects to a failover server)
2. support scenarios where new subscribers must receive all past messages that were published.

Of course this can be handled at the application layer...but that is not what I am looking for.

EDIT

So, after some research the following installed options seem to be the most robust:

• Kaazing Migratory
• Migratory (http://migratory.ro)

Hosted services that seem "real"

• Pusher (great API but no history feature yet)
• PubNub (has history)

All of the above services have graceful fallback to other communication methods if websockets are not available.

I was not able to find any open source that provided "out of the box" clustering, fail-over, and a durable message store to play back history. There are some projects that may serve as good starting points, but not exactly what I am looking for.

Hornetq is a general message broker that supports JMS, STOMP and Websockets+Stomp. It provides durability of messages along with a host of other features.

What do you mean by channel data?

It should be the duty of an application that runs within the server to take care of the data (think LAMP).

Just think of how much data is saved when you make an HTML file with a form that posts to itself and just put that in a plain apache. All "form-data" is lost, after every single request.

EDIT:

You are on the wrong track.

Websockets don't have any relation to persistence or durability, neither does SMTP, HTTP or IMAP. It is just a transport description. (Heck, not even syslog is talking about persistence in the RFC)

I don't know what you're looking for but I'm pretty sure that it is not durability of the bytes sent or received by a websocket, rather it is durability of the data constructed after the bytes have been sent.

This problem has been solved a couple of times, I'll just reference the standard RDBMS frameworks:

• Hibernate (java)
• SQLAlchemy (python)
• ActiveRecord (ruby)

If you only send JSON you can just as well use some non-relational store like Riak, Redis, MongoDB, CouchDB.

Of course it's up to you to parse the data and create someting from it that will work for your setup. I hate to say it but saving what's sent over a websocket without knowing the meaning of it is just about the same as taking a tcpdump and then reading it with ed.

May I suggest to migrate this question over to stackoverflow I don't think that serverfault is the right place for framework architecture and development.

To address the part of the question which asks if Pusher is durable I can confirm that if a user that was connected to the Pusher service and the WebSocket server that they were connected to died that they would be automatically reconnected to another WebSocket server. Channel data only exists within the WebSocket server as transient data and we have an entirely separate system which allows our WebSocket servers to distribute and consume information from connected clients. For the moment we do not persist information within Pusher. The data is simply distributed between connected components such as our REST API and connected clients.

At the moment if messages were sent during a client reconnect that user would miss those messages. However, we are implementing channel history which would mean that we will persist data within channels. This would mean that any messages that a user has missed can then be retrieved. Since our WebSocket servers would not deal with the persistence of data if we lose a WebSocket server we would not lose the channel data.