Hi Staffan, > Looked the e-mail outlining the proposed wire format; it looks > good. That's essentially equivalent to what I did in my quick-n-dirty > prototype, only with larger cmd-id and algo-id fields. Is there a > specific reason to use 16-bits for the cmd-id? Seems like one byte would > more than suffice, wasting a byte is not a big deal though.
The only reason being is alignment of payload to 32-bits as all good network protocols do :) This is useful only in special circumstances though (packet-based transport mechanism, routing implemented in silicon) so as you say, no big deal. > How do you propose to solve the problem of intermediary devices not > necessarily being aware of all matching methods? Change XPUB/XSUB > semantics, new socket type? Nope. What can be done is that if the code is not aware of particular matching algorithm, it transparently passes the subscription upstream. Also it marks the downstream node that it've got the subscription from as subscribed for *all* messages. This allows old devices to work with new matching algorithms, although in a less efficient way. Martin _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
