[zeromq-dev] 0MQ protocol stack

Martin Sustrik sustrik at 250bpm.com
Fri Apr 8 08:04:47 CEST 2011


Hi Martin,

>
>     The only thing changed atm is that the TCP connection initialisation.
>     Instead of a simple message, a multipart message is sent where each part
>     constitutes one property.

> I believe this is not only TCP related, right? All transports need to
> cover the same functionality.

Nope. It is transport-specific.

Initiation kind of make sense for TCP, but for PGM it cannot be done. 
Same thing with subports. Heartbeats could be built on top of TCP but 
are useless on top of SCTP. Etc. Message offset thing makes sense for 
PGM or other packet-based transport, but makes no sense for TCP or SCTP. 
Etc.

> Just my thoughts as I am thinking about SCTP transport for zeromq. And
> since zeromq transport already mimics some of SCTP features (message
> boundaries, many to one style), it would be great also to have other
> features like the aforementioned notifications and e.g. heartbeating
> also for other transports.

The important point here IMO is that different underlying transports 
provide different functionality. Trying to pretend they are all the same 
makes little sense and is definitely not in scope of 0MQ project.

The transport-specific layer of 0MQ should be as thin as possible, 
providing only those features that are necessarily needed to run 0MQ on 
top of the transport. At the moment, as far as I am aware, it's only 
message segmentation for transports that are either stream- or packet-based.

If one wants to improve TCP or somesuch, he should build a special layer 
on top of it (think SPDY). That could then be used as a transport for 0MQ.

Martin



More information about the zeromq-dev mailing list