Thanks Pieter,
I assume that when the message comes here:
int zmq::stream_engine_t::write (const void *data_, size_t size_)
which executes:
ssize_t nbytes = send (s, data_, size_, 0);
the peer receives the same with the same number of recv commands ?
Corollary is that there is no data aggregation of two or more send in a
buffer before it goes on the wire, and on the other side recv gets the
same size of data than its send counterpart. Is it still true with all
transports, in particular inproc ?
Sorry for the naivety of the question.
Bonne nuit,
Laurent
Le 17/01/2014 15:30, Pieter Hintjens a écrit :
You can't add to a message without breaking ZMTP. What you could
conceivably do is inject command frames, and filter these out.
On Fri, Jan 17, 2014 at 2:57 PM, Laurent Alebarde <[email protected]> wrote:
For trimming an incoming message, the very beginning of in_event looks like
the right place.
For prepending an outgoing message, I would guess out_event just at the
beginning of the if (!outsize) block. But I am not sure.
What is the granularity of what is written with out_event / int nbytes =
write (outpos, outsize); , frame ? message ? several message possible ? part
of a frame possible ?
Le 17/01/2014 11:40, Laurent Alebarde a écrit :
Hi Devs,
I am doing some experiments (cf at the end for the goal) and wonder where I
could hook the beginning of a message both reading and writing.
What I want to do is prepend an outgoing message and trim an incoming
message (for any mechanism looks simpler) when some option is set.
Typically, when the option is set, when a new message is received, I want to
be able to store a certain amount of the first bytes in a new mechanism
buffer, and skip them. These bytes are experimental and not ZMTP, so I have
to skip or trim them to not hurt ZMTP. When a message is sent, I want to
initialise the buffer with a copy of what I previously stored before ZMTP
write the buffer. If it is outpos, I will do outpos += store_size;
So, the question is where & when I should do that to not hurt ZMTP.
FYI, The aim of this experiment is to manage to achieve CURVE proxying. My
investigations and tests so far lead me to prepend the client ID in every
message sent to the CURVE worker, and that the worker send back this
information.
Cheers,
Laurent
_______________________________________________
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
_______________________________________________
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
