[nanomsg] Re: nn_recv with padding
- From: Drew Crawford <drew@xxxxxxxxxxxxxxxxxx>
- To: nanomsg@xxxxxxxxxxxxx
- Date: Mon, 12 May 2014 06:10:39 -0500
I’m not completely sure I’ve expressed my problem intelligibly, but my goal is
to produce a zero-copy contiguous array of (let’s say) messageSize + 16, with
the extra bytes leading or trailing as desired.
As far as I comprehend the documentation, nn_recvmsg allows me to receive data
into a *non*contiguous array. But I don’t know how to use it to produce a
contiguous array of messageSize + 16.
On May 12, 2014, at 5:59 AM, Martin Sustrik <sustrik@xxxxxxxxxx> wrote:
> Signed PGP part
> Hi Drew,
>
> > which would require memcpy to copy into a buffer with space for
> > padding. Ideally I would like something like
> >
> > struct nn_padding_description { int paddingSize = 20; int
> > paddingType = NN_PREPEND; }
> > nn_recv(socket,&buf,padding_description,NN_LENGTH_IS_PADDING_DESCRIPTION_NOT_ACTUAL_LENGTH);
> >
> >
> >
> An alternate idea would be some way to find out the size in advance
> >
> > int size = nn_peeksize(socket,options); uint8_t buf[size +
> > padding]; rc = nn_recv(socket,buf,size,0);
> >
> > This approach has the advantage of supporting size-dependent
> > padding schemes (for example, padding that is exactly double
> > message length) but there may be some implementation detail why
> > message size cannot be known in advance.
>
> Actually, the API is already suited to do this via gather/scatter
> arrays. It's implementation that's lacking: It doesn't support more
> than one NN_MSG buffer per nn_sendmsg call.
>
> If you want to fix the implementation you are welcome, of course.
>
> Martin
>
>
Other related posts:
