[zeromq-dev] Connection setup

Martin Sustrik sustrik at 250bpm.com
Wed Apr 21 14:30:03 CEST 2010

Hi Brian,

> Just a few more newcomer comments after having a bit of a play with 0MQ.
> I like the idea of having different messaging models bound to different
> connections.  It avoids having to tag each individual message as "this is a
> PUB with a topic", or "this is a REQ which expects a REP", thus saving those
> 8 magic flag bits for other uses, and simplifying the code which receives
> messages.  And it's reasonable to assume that all the messages in a
> particular flow are going to follow the same pattern.
> However, it does allow for some errors; for example, you can happily connect
> a P2P client to a REP server.

Yup. A known problem.

> There is an existing initial handshake, which at the moment does nothing
> more than exchange peer identities (*).  Maybe it should also say "I'm a
> REQ" or "I'm a P2P"?  Then the connection could be dropped if it was an
> inappropriate peer.

That would work as long as you are using bi-directional transport such 
as TCP. How should the problem be solved say with PGM which is 
inherently uni-directional and moreover receivers can join the feed at 
any point?

> Now, if you're going to say "I'm a REQ", then you could instead say "I need
> to connect to a REP peer".  This means you could run multiple message
> patterns on the same port, and provide whichever the client asks for, if the
> server wishes to support them.  Extending this further, the client could ask
> to talk to a named service, so that multiple distinct services could be
> served from the same port.

That's a tempting solution as it provides a way to tunnel all the 
traffic throught a single open port in a corporate firewall.

However, it doesn't allow for systematic traffic shaping and network 

Moreover, it can be argued from the security point of view that if 
there's a new feed/service crossing the corporate firewall, passing the 
audit/approval process to open a new port is exactly the thing that 
should be done. Passing all the traffic indiscriminately through a 
single open port with no process to control it doesn't seem like a good 

> There are other uses for the initial handshake: e.g. requesting TLS,
> providing authentication. Or you could declare the MIME type of the messages
> you intend to send, which could also prevent some other foot-shooting.
> Anyway, given an empty initial message exchange all this can be easily
> retro-fitted, which is a good position to be in :-)


> (*) I can't see how the local identity is set, or the remote identity is
> read, in the current API.  Have I missed something?

It's about resources. Say you want the queue to hold at most 1000 
messages from each client. If client sends 1000 messages, then 
disconnects, reconnect and sends 1000 messages more, there are 2000 
messages from the same client in the queue. The server has no way to 
tell whether it's the same client or a new one. That's what identity is for.


More information about the zeromq-dev mailing list