Actually that looks OK stepping through it, but I wondered if the sent messages are getting put onto the pipe first. The other code kind of assumed this was the first thing that would happen, but in this case send is called twice before the pending connect executes - so the identity flag msg is the 3rd message written into the pipe.
That is quite a tricky one to resolve! I guess we could unwrite() the messages from the pipe, buffer them up, write the new one, and carry on that way, but that is potentially a bunch of copying. On 4 February 2014 22:41, Ian Barber <[email protected]> wrote: > Not sure that codes the root cause there, though it may be swallowing the > part its been around for a while. Suspicious its the changes to allow > connect before bind on inproc playing badly with something, Worth a look to > see if its the recv_identity type options not being picked up properly in > ctx:connect_inproc_sockets. > > Ian > > > On 4 February 2014 20:13, Pieter Hintjens <[email protected]> wrote: > >> Hi all, >> >> Issue https://github.com/zeromq/libzmq/issues/872 causes message >> corruption over inproc and dealer-router. >> >> Test case is at: >> >> https://github.com/zeromq/issues/commit/58bd49421e8b2d06761eda838cbe311b754d7f62 >> >> The fault is IMO in router.cpp, around line 414: >> >> if (msg.size () == 0) { >> // Fall back on the auto-generation >> unsigned char buf [5]; >> buf [0] = 0; >> put_uint32 (buf + 1, next_rid++); >> identity = blob_t (buf, sizeof buf); >> msg.close (); >> } >> >> which replaces an empty initial message with an ID frame. If the first >> message isn't empty, the ID frame isn't generated at all. >> >> Anyone have an idea? >> >> -Pieter >> _______________________________________________ >> zeromq-dev mailing list >> [email protected] >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev >> > >
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
