The TCP EventBus bridge is built on top of TCP, meaning that any application that can
create TCP sockets can interact with a remote Vert.x instance via its event bus.

The main use case for the TCP bridge versus the SockJS bridge is for applications that are more
resource-constrained and that need to be lightweight since the whole HTTP WebSockets is replaced with plain TCP sockets.

It remains of course useful even for applications that don’t have tight resource constraints:
the protocol is simple enough to efficiently provide an integration interface with non-JVM
applications.

The protocol has been kept as simple as possible and communications use Frames both ways.
The structure of a Frame looks like this:

The message consists of a JSON document that may or may not have been minified.
The message must be prefixed by a big endian 32 bits positive integer (4 bytes) that indicates
the full length of the JSON document, in bytes.

The message type can be the following for messages sent by the TCP client:

send to send a message to an address,

publish to publish a message to an address,

register to subscribe to the messages sent or published to an address,

unregister to unsubscribe to the messages sent or published to an address.

Note that the replyAddress field is optional and may only be used for a send message.
A message with that field is expected to eventually receive a message back from the server
whose address field will be that of the original replyAddress value.

The server posts messages back to the client, and they can be of the following type:

message for messages sent or published to an address, or

err to indicate an error (the body shall contain details).

An example NodeJS client is available in the source of the project.
This client uses the same API as the SockJS
counter part so it should make it easier to switch between the TCP and SockJS implementations.