[zeromq-dev] Router drops empty first frame on inproc://

[Goswin von Brederlow]

On Tue, Feb 04, 2014 at 11:15:21PM +0000, Ian Barber wrote:
> 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.

Could you write the identity message to the pipe first, or a dummy
message. And then when the connect executes you fill in / swap the
dummy for the real identity message?

> On 4 February 2014 22:41, Ian Barber <ian.barber at gmail.com> 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 <ph at imatix.com> 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

MfG
	Goswin