On Mon, Jun 10, 2013 at 5:41 PM, Ciprian Dorin Craciun < ciprian.crac...@gmail.com> wrote:
> > 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). > One thing to plausibly consider is making the identity generation algorithm part of the spec (perhaps optionally). Rather than a UUID or other random based item, it could be based on the 5-tuple of the connection or similar - which would mean reconnects would get the same identity transparently. Then the sender would have the option of controlling this via that mechanism even if clients didn't send identities. Re the rest of the protocol, took a quick look, it all looks good. Share the concerns about out-of-order delivered, but I am not sure that can relevantly happen in a way that can't right now - the only case that makes sense is if the connection comes back and then a earlier messages gets delivered after a newer one to the same host. In that case we could probably resolve it by not requeing to the same identity as before. Not sure whether the book keeping is worth it. Secondly, it raises the possibility of a bad message killing multiple services. The other general niggle I have is reusability of this onto PGM/UDP/IPC. Most, but not all of the socket semantics and ZMQ frame structure are shared, but there are protocol specific features baked in (e.g. publisher side filtering). I'm not sure whether the appropriate way around is to separate generic and protocol specific behaviour, or create additional specifications that describe the functionality in terms of variance from the ZTMP base-spec. I'd be willing to have a go at specifying one of those if that's a way we think is sensible (might clarify the decision a bit). Ian
_______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
