On May 26, 2011, at 2:18 PM, Martin Sustrik wrote: > On 05/26/2011 08:49 PM, Pieter Hintjens wrote: >> On Thu, May 26, 2011 at 11:41 AM, Li, Jia<[email protected]> wrote: >> >>> I see. How about adding a paragraph in the Guide to describe this behavior, >>> just like it does warn about mixing socket types in devices? Since zmq is >>> advertised as it-just-works, I was a little disappointed when it didn't and >>> the user wasn't warned beforehand. >> >> Indeed. I didn't even know it worked like this... :) My understanding >> was that connect/bind were orthogonal to message flows but in fact it >> seems that's not always the case. We learn something every day... > > Here's some background: The algorithm was implemented the "consistent" > way first. The connecting side dropped messages if the connection was > not established. > > This caused a lot of puzzlement among users. You would expect following > sequence of commands to actually send the message to the peer: > > zmq_connect (s, "..."); > zmq_send (s, msg); > > The problem is that connecting is asynchronous and takes certain amount > of time. Thus, when send is executed, the connection doesn't exist yet > and the message is dropped. > > So, what I did to make the behaviour more user friendly was to create a > "queue" as soon az zmq_connect() is called. It is then attached to the > actual network connection when it is established.
Please don't change this behavior. cr _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
