[zeromq-dev] Useless client/server byte

[Fabrice Bacchella]

The specifications for ZMTP 3.0 and 3.1 reserve a byte to indicate that one side is an authentication client or server:

;   The greeting announces the protocol details
greeting = signature version mechanism as-server filler
...
;   Is the peer acting as server for security handshake?
as-server = %x00 | %x01

Looking at the current git, it looks like it’s not handled, neither in writing or reading:
 
In libzmq/src/zmtp_engine.cpp, line 220 commit bdd471f (https://github.com/zeromq/libzmq/blob/bdd471fa17100fe84f64da348951dab3ee4780bb/src/zmtp_engine.cpp#L220)

and in libzmq/src/zmtp_engine.cpp, line 345 commit bdd471f (https://github.com/zeromq/libzmq/blob/bdd471fa17100fe84f64da348951dab3ee4780bb/src/zmtp_engine.cpp#L345)


With Curve for example, when two clients are connected, they wait for the other side infinitely, without any warning or error, that’s a reliability problem.

There is actually an open discussion about it at https://github.com/zeromq/libzmq/issues/2821.

I think it opens a lot of questions, and many way to handle that problem, and need a discussion with different port for interoperability.

First, I think it should be always set when it’s send. It helpful at least for debugging using wireshark or similar tools. And two server (both value set to 1) could fails with an explicit message instead of a generic one.

Next, the questions is how to handle it at reception. My proposition is to add two things:
	• a socket option ZMQ_CLIENT_SERVER_STRICT, to be set of both side to have strict conformance.
	• a ZMQ_PROTOCOL_ERROR_ZMTP_CLIENT_SERVER_MISMATCH error, used by monitors.

But there is discussion about how to handle backward compatibility with other implementation or older revisions. I think an option is enough, as we can assume that people that activate it knows that it does and role back is easy.
As a socket option, it can be choose for each connection.

Another option is to release a ZMTP RFC 3.2 that either make check mandatory or add values:
0 — hint as a client
1 — hint as a server
2 — client as a mandatory information
3 — server as a mandatory information.

But that possibility is also a problem. RFC 3.1 define a resource metada and other changes. So implementation that are still at 3.0 compliance would need support 3.1 before upgrading to 3.2. That raise the difficulty to use this feature.

There is also a lot of room in the filler for version 3 or latter that might be used too, and that will be ignored by versions not using it. The meaning would be:
0 — not used, ignored (the usual value)
1 — client
2 — server

Perhaps that could be specified in a optional RFC extension, independent of the ZMTP version.
A magic cookie could be added at the start of the filler to indicate that it’s meaningful.