[zeromq-dev] Socket type checking

[Martin Sustrik]

Hi all,

I guess there are two separate problems there. As Pieter puts it there's 
a "breakfast" problem and the "egg" problem.

We have no good idea how to solve the "breakfast" problem, so let's move 
the "breakfast" discussion to the SP mailing list and focus on the "egg" 
here, namely on what kind of type checking we are able to provide today 
and in a backward compatible way. One additional requirement, IMO, is 
not to expose the functionality directly at the API level. That way, if 
the mechanism is improved or changed in the future, it won't cause 
existing applications to be re-written.

As I've mentioned in my previous email there are 3 different layers 
involved: TCP, 0MQ and Application.

We are definitely able to provide type checking at 0MQ level today - 
just send a socket type ID to the peer and check the peer's type ID for 
compatibility (PUB with SUB, REQ with REP etc.)

The TCP and Application level type checking is not that clear. However, 
we can pass opaque data to the peer instead of a well-defined socket 
type ID. That way the mechanism can be used for additional type checking 
if needed.

At the moment I would say sending an UUID representing the socket type 
would be the best. Being a 128-bit random BLOB, there's no realistic 
chance that a non-0MQ connection would begin with exactly the same 128 
bits by accident. Which solves the type checking at TCP level in a way.

As Ilja and Paul say, application-level type checking is more important 
to the users than either TCP or 0MQ-level type checking. I believe that 
the UUID can be used to identify a topology (Application level type 
checking) in the future. At least in theory, that is.

Martin