[zeromq-dev] Socket type checking

Martin Sustrik sustrik at 250bpm.com
Wed Nov 9 08:41:00 CET 2011

On 11/05/2011 03:32 PM, Pieter Hintjens wrote:
> On Sat, Nov 5, 2011 at 1:32 PM, Martin Sustrik<sustrik at 250bpm.com>  wrote:
>> If you have any concrete improvement in mind, feel free to propose it.
> There are a set of things we wanted to add to the protocol, such as
> socket type checking.

Sorry for the delay. This one is a complex problem so let me share some 
random half-baked thoughts about it:

The obvious solution is that each peer sends its socket type to the 
other peer, which in turn verifies it and drops the connection if it is 
incompatible with the advertised socket type.

Now, consider that this kind of mechanism is needed at at least three 
layers of the stack:

1. TCP. Identifying TCP services such as SMTP vs. SSH vs. HTTP. This 
mechanism exists => TCP ports.

2. 0MQ. Identifying different 0MQ services such as PUB/SUB vs. REQ/REP 

3. Application. Identifying different application level services 
(topologies). For example, stock quote distribution vs. video chat 

The above problem can be solved in two basic ways: either use a separate 
"type negotiation" mechanism at each level, or try to unify it in some way.

The first option is pretty obvious and easy to implement. However, there 
are several problems with it:

a. It doesn't solve the problem of non-0MQ application (SMTP or 
whatever) connecting to 0MQ application (pt 1 above).

b. It can be done on 0MQ level (pt 2) but it's not clear how to do it on 
the application level (pt 3) especially when the pattern in question is 
unidirectional or unreliable. The only option available seems to move 
application level type-checking to 0MQ which in turn suffers of the 
other problems mentioned in this list.

c. It doesn't play well with unidirectional or unreliable transports. To 
do type checking we need to pass the type in both directions and in a 
reliable way.

d. The type checking mechanism is not a generic feature. It's different 
for each transport protocol. Type checking for TCP is different from 
type checking for SCTP as the two cannot speak together anyway.

e. Different messaging patterns are orthogonal non-intersecting 
protocols that happen to be bundled in a single library (libzmq). You 
can think of it as say a single library providing TCP, UDP and SCTP 
support. However, type checking is a universal feature that cuts across 
all these protocols. Intuitive reaction of a protocol designer would be 
to move it to a common underlying layer thus (TCP and friends).

The above leads us to a second possible solution, which is providing a 
unified, transport-agnostic type checking system.

The idea of this solution is to provide the type checking in the single 
layer, namely the transport layer which is common to all the patterns. 
In practical terms it means, for example, using TCP ports to identify 
particular service on TCP, 0MQ and application level.

The second component of the solution should be a system for mapping the 
high-layer type (topology, e.g. "NASDAQ stock quotes" to lower-layer 
types (i.e. PUB/SUB on 0MQ level and port 5555 on TCP level).

This second solution makes more sense IMHO, but, at the same time, 
requires much more work and experimentation to get it done.

Uh. That was long...


More information about the zeromq-dev mailing list