[zeromq-dev] Raw protocol spec for REQ/REP socket?
Pieter Hintjens
ph at imatix.com
Tue Apr 26 09:39:58 CEST 2011
On Tue, Apr 26, 2011 at 9:23 AM, Martin Sustrik <sustrik at 250bpm.com> wrote:
> The protocol is likely to change in the future, however, if you believe it's
> worth documenting 2.x protocol, it consists from 2 pieces:
>
> 1. First message sent by each party on a connection is identity. Empty
> message means no explicit identity was specified. This point is specific to
> TCP and IPC transports. It applies to all socket types.
>
> 2. REQ/REP messages consist of a list of labels (each label is a message
> part) followed by an empty message part. All remaining message parts are
> user data.
Martin,
I'm surprised that you even ask whether it's worth documenting the 2.0
protocol. Allow me to rant a little.
- the lack of a documented protocol severely handicaps 0MQ's status,
allowing critics to (accurately) portray it as "just" a DLL, not an
interoperability project.
- this lack is a severe (total) barrier to independent
interoperability, i.e. other stacks that can talk to 0MQ. This means,
no JavaScript support, for example.
- this lack is a primary cause IMO of some severe design flaws in the
actual protocol e.g. the lack of socket type validation. This would
have shown up as an obvious flaw before v1.0 and fixed long ago, first
in the specs, then in the code. Also, no attempt at versioning, so no
backwards compatible changes, after 3 years of development.
- this lack prevents exploration in areas such as security, functional
extensions, other transports, etc. If 0MQ is over-dependent on libzmq
(and I believe it is), this is largely due to the lack of proper
interoperability specs.
I can go on. There have been several people asking for these specs in
the last weeks. It's frankly embarrassing to point to man pages and
tutorials when we _know_ how to write proper RFCs. After all, you were
project manager for AMQP for over a year.
End of rant.
Your answer of "the pieces are there, go ahead and document them" is
fine, and I'll do that, except that specifications are contracts and
you've not indicated any intention to participate in such a contract.
And unless you're party to such contracts, Martin, they have no
weight. The software version number should not define wire-level
interoperability. That should be defined by a WLP spec version number.
It would be better if you put together the text, even in rough shape,
as a statement of intention to move more towards design by contract
and less design by code. But let's accept that the pieces that already
exist more or less form a contract...
If I do document the 2.0 protocol, will you use that as a basis for a
3.0 draft specification _up front_ so we can discuss that, improve it,
and make sure it's sane, _before_ you start implementing a new
protocol in code?
-Pieter
More information about the zeromq-dev
mailing list