- Created a new option ZMQ_ROUTER_RAW_SOCK
- Added new raw_encoder and raw_decoder to receive and send messages in raw form to remote client
- Added test case file tests/test_raw_sock.cpp
o To create a raw router sock set the ZMQ_ROUTER_RAW_SOCK option
o ZMQ_MSGMORE flag is ignored for non-id messages
o To terminate a remote connection send id message followed by zero length data message
This is supposed to become part of the ZMTP/1.1.
The main differences from the ZMTP/1.0 framing protocol are:
- flags field comes first, followed by the length field
- long messages are signaled using a flag rather then 0xff escape
- length field does not include the flags field, 0 is a valid value
Since ZMQ 2.x does not support subscription forwarding, it's not
possible to use ZMQ 2.x SUB socket to receive messages from a PUB
socket.
This patch adds some compatibility layer so that ZMQ 2.x SUB socket
receives messages from PUB socket.
The new protocol adds support for protocol version and exchanges the
socket type, so that the library can reject a connection when the
sockets do not match.
The protocol was designed so that it's possible to detect and fully
support ZTP/1.0 peers.
When a new connection is set up, peers exchange greeting messages. The
greeting message encodes both the protocol verion and the socket type.
The format of the greeting message is as follows:
greeting = tag1, adaptation, tag2, version, length, socket_type
tag1 = BYTE / 0xff
adaptation = 8 BYTES
tag2 = BYTE / 0x7f
version = BYTE / 1
length = BYTE / 1
socket_type = BYTE
The protocol does not define the value of adaptation field.
When interoperability with ZTP/1.0 peers is required, the adaptaion
encodes, in network byte order, the length of identity message increased
by 1. When adaptaion consists of eight zeros, the current
implementatatio of 0MQ 2.x closes the connection.
This patch supports both ZTP/1.0 and new protocol.
Before this patch, the stream engine terminated itself
whenever it had detected an IO error. If this happened
when sending a message, the engine lost all
in-flight messages, messages waiting to be decoded,
and the last decoded message that had not been accepted,
if there was one.
The new behaviour is to terminate the engine only after
the input error has been detected and the last decoded
This is a preliminary patch allowing for socket-type-specific
functionality in the I/O thread. For example, message format
can be checked asynchronously and misbehaved connections dropped
straight away.
Signed-off-by: Martin Sustrik <sustrik@250bpm.com>
The engine was not used exclusively for TCP connections.
Rather it was used to handle any socket with SOCK_STREAM
semantics. The class was renamed to reflect its true function.
Signed-off-by: Martin Sustrik <sustrik@250bpm.com>
