[zeromq-dev] subports

Pieter Hintjens ph at imatix.com
Wed Jul 27 11:50:02 CEST 2011


On Wed, Jul 27, 2011 at 11:11 AM, Martin Sustrik <sustrik at 250bpm.com> wrote:

> I am not a user so I am not really competent to answer. However, at San
> Francisco meetup early this year, subports were identified as the most
> desired feature to add to 0MQ.

I don't want to be negative. This is literally accurate, but what
you've made is not "subports" as people hope to see, and it's about
the third time we have this thread :-).

At SFO we discussed both tunneling and in-process subports, and
consensus demand was for in-process named subports.

One quite significant problem with complex 0MQ apps is having to open
and manage multiple ports. It's both a firewall and a topology issue.
It is *significantly* more complex to manage 2+ ports than one port.
It's made worse by the design pattern of splitting different flows
into separate sockets. One example cited had to open 4 sockets (across
a firewall, no less).

Named in-process subports would work as follows: server binds one
socket to e.g. tcp://*:9001:control and a second socket to
tcp://*:9001:data. Clients connect to
tcp://192.168.55.201:9001:control or tcp://192.168.55.201:9001:data
depending on the specific service _within that process_ they need. The
peers would do a normal TCP connection and then specify the subport in
the connection handshake.

Also discussed at the time:

* In-process subports would presumably allow tunneling, but not vice-versa
* Subports would need to be named, not numbered.

-Pieter



More information about the zeromq-dev mailing list