On Mon, Jun 10, 2013 at 4:45 PM, Pieter Hintjens <[email protected]> wrote:
> The criteria for adding something to ZMTP is that it solves real
> problems we face today with ZeroMQ applications. No speculative or
> "could be useful" engineering, please.
Fair enough, thus I'll drop the rest of the debate, except the
issue related to the "optional" status of the identity (see below).
> If you want to experiment with variations of ZMTP, the spec is GPL
> licensed specifically so that you can fork it freely.
I don't think it's a good idea to have n ZMTP-cloned protocols...
In the long term I would prefer a single less than ideal protocol,
than a thousand "perfect" ones. :)
>> I don't get this, mainly because I didn't follow closely enough
>> ZeroMQ developments. But isn't the identity of the remote peer chosen
>> by that remote peer itself? In this new version the identity is
>> chosen by the local peer?
>>
>> I would think that enforcing identity specification could at least
>> help in debugging, manly because it's the only way in which you can
>> determine the source of a message (if the source isn't embedded in the
>> message by the application).
>
> Sorry, you need to read up how ZeroMQ identities work (REQ, DEALER,
> ROUTER talking to ROUTER sockets only). They're not a generic
> mechanism. The name is poor; it's a reply routing handle.
I know how v1 of the protocol worked, and what purpose the
identity plays. I'm not arguing in removing it from the greeting.
I'm just arguing that the specification makes the identity
"optional" for those socket types that actually use it, namely
`DEALER` and friends...
And the following are my arguments:
* if the identity is not sent by the other peer, then the local
peer will have to "invent" an identifier for it, just to present
something to the application to be used in further routing; thus even
though the identity is optional in the protocol it's actually
mandatory in the overall picture (for certain sockets);
* if the connection "breaks" in the following way: the remote peer
receives `RST` (or another software error), meanwhile the local peer
doesn't, the remote will try to reconnect; however because the remote
doesn't send the identity, the local peer interprets that connection
as a new one, with the following consequences:
* it consumes resources on the local peer, which could have
closed the old connection and replaced it with the new one; (although
this one is solved with timeouts and heartbeats;)
* any outstanding replies are dropped, even though they could
have been sent through the new pipe (minus the ones already sent
through the broken pipe);
As such I'm only saying that by making the identity mandatory (at
least in a couple of sockets, or even in the others as seen from the
second example) can only make the protocol more robust.
However, in retrospect I will not waste more time on this. Even
if it remains optional, any well-behaved library can actually send the
identity (thus becoming de-facto as mandatory).
Ciprian.
_______________________________________________
zeromq-dev mailing list
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
