Re: [zeromq-dev] "Who said that?"

[Oliver Smith]

Martin Sustrik said the following on 12/21/2010 2:08 AM: On 12/20/2010 09:21 PM, Oliver Smith wrote: Martin Sustrik said the following on 12/17/2010 5:15 AM: By bad data you mean malformed 0MQ frames? With 2.1 those are discarded silently and the connection is closed. We should also report the problem via sys://log. No, it's probably data getting reused before it is transmitted - i.e. my issue, but it's very hard to track down because I don't know which of the many nodes is sending it :) The only way I can track that down is to send everything to separate ports and collate at the receiver, until I'm done debugging, and then reunify all of them again. Ok. So what's needed is message tracking for debugging purposes. Fair enough. So what about, for example, writing a simple wrapper over zmq_send() that would attach a message part containing identity of the particular node to every message? Ah - I was arguing this particular incident as one of several reasons why it might be beneficial to have access to the prior-hop information above (i.e. in the application) the zmq_recv(). Another being WAN-transit cases where you do want to avoid exposing any form of internal network-state information from the sender into the packet beyond what is already deducible. That is: you don't actually care what the IP address and port of the last-sender/forwarder are, just that one is different than the other. [Image: An application calling recv() on a single zmq::socket which is abstracting multiple bsd::socket or inproc sockets connected to any number/type of sources] Another use case: cache efficiency. lastSrc = None cache = None while True:     msg = zmqSock.recv()     src   = msg.socketMuxDistinguisher()     if src != lastSrc:         cache = cacheForSrc[lastSrc]     doWork(msg, cache)     if itsTimeForACacheCheck():         expireOldCaches() It could be made exceedingly clear that this is NOT any form of a source/return address by allowing the user to provide the local distinguisher. I'm not proposing, in any way or form, that this provide a value that the user ever pass to any ZMQ function.

_______________________________________________
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev