Warlock to implement WebSocket server protocol

jamie commented

2014-07-30 00:36:28 +00:00

(Migrated from git.hazaar.io)

See #32 for why I'm doing this.

The protocol for communication between the Warlock Client controller and Warlock Server will become WebSocket protocol (inc. handshake). This will then allow us to convert from a unix socket file to a TCP socket easily and then support direct connections to Warlock from the web browser using WebSocket clients.

All of this will allow for fall-back to the current method which uses long-polling HTTP connections.

See #32 for why I'm doing this. The protocol for communication between the Warlock Client controller and Warlock Server will become WebSocket protocol (inc. handshake). This will then allow us to convert from a unix socket file to a TCP socket easily and then support direct connections to Warlock from the web browser using WebSocket clients. All of this will allow for fall-back to the current method which uses long-polling HTTP connections.

jamie commented

2014-09-19 00:28:06 +00:00

(Migrated from git.hazaar.io)

WebSockets support is now completed and working perfectly. Now it's just a matter of adding back the legacy support using the /warlock/listen endpoint and long polling.

At this point I'm not sure whether to have this continue to connect via Apache, or to support connection via HTTP long polling directly to Warlock. There are advantages and disadvantages of both.

Direct connection allows more simultaneous connections without clogging up Apache connections that have limits.
Connect via warlock means I need to implement a mini HTTP server which will be a bit more work.

WebSockets support is now completed and working perfectly. Now it's just a matter of adding back the legacy support using the /warlock/listen endpoint and long polling. At this point I'm not sure whether to have this continue to connect via Apache, or to support connection via HTTP long polling directly to Warlock. There are advantages and disadvantages of both. * Direct connection allows more simultaneous connections without clogging up Apache connections that have limits. * Connect via warlock means I need to implement a mini HTTP server which will be a bit more work.

jamie commented

2014-09-19 00:32:21 +00:00

(Migrated from git.hazaar.io)

It is decided... I'm going to implement both, but in two stages.

First stage will be direct connections and implementing HTTP support in Warlock. I can already parse HTTP headers because we have had to do this for the WebSockets handshake so it shouldn't be too difficult. I think the only real difference is that after we send data we have to disconnect. Other than that most things are the same.
Second stage will be adding support for long polling via the application (ie: apache). Turns out this might actually be a bit hard to implement because I have to implement a WebSockets client in the application.

It is decided... I'm going to implement both, but in two stages. * First stage will be direct connections and implementing HTTP support in Warlock. I can already parse HTTP headers because we have had to do this for the WebSockets handshake so it shouldn't be too difficult. I think the only real difference is that after we send data we have to disconnect. Other than that most things are the same. * Second stage will be adding support for long polling via the application (ie: apache). Turns out this might actually be a bit hard to implement because I have to implement a WebSockets client in the application.

jamie commented

2014-10-14 04:02:01 +00:00

(Migrated from git.hazaar.io)

Everything is done! WebSockets is now the default protocol and is used when the application communicates with Warlock. It is also used by browsers that support it. If websockets is disabled or the browser does not support it then the connection falls back to legacy (long-polling) mode. Long polling can also be manually selected as well if needed by setting warlock.useWebSockets = false before calling subscribe().

Services have also been updated and now allow for two way communication and full signalling support. The Warlock control panel has also been updated and includes RRD graphs, better signalling support and service control.

Everything is done! WebSockets is now the default protocol and is used when the application communicates with Warlock. It is also used by browsers that support it. If websockets is disabled or the browser does not support it then the connection falls back to legacy (long-polling) mode. Long polling can also be manually selected as well if needed by setting _warlock.useWebSockets = false_ before calling _subscribe()_. Services have also been updated and now allow for two way communication and full signalling support. The Warlock control panel has also been updated and includes RRD graphs, better signalling support and service control.

jamie commented

2014-10-14 04:02:01 +00:00

(Migrated from git.hazaar.io)

Status changed to closed

Rows
Columns

Warlock to implement WebSocket server protocol #33