Hi Lei,
Lei Jiang writes:
> What I meant was, ZMQ seems to keep multipart message frames together. I
> wrote some test code, in the same
> thread, sending interleaving frames using 2 sockets like this.
>
> ZMQFrame("frame 1-1").Send(client1, ZMQ_SNDMORE);
> ZMQFrame("frame 2-1").Send(client2,
Hi Lei,
I didn't really follow this email thread closely but I happened to read
this:
I think it suggests that as long as the "active" message has not finished,
> meaning it's still sending the "MORE" flag, a ROUTER socket will not
> receive() a frame from a different client. Given that the proxy
Hi Brett,
Sorry for the late reply!
On Fri, Nov 3, 2023 at 12:40 AM Brett Viren wrote:
>
> > A long multi-part message could potentially lead to embarrassing
> > situations quite easily. Even when the proxy code is fast, if
> > something gets stuck in either the request or the response, for
>
"Axel R." writes:
> @Brett: You wrote:
>
> Not reliability per se but messages will not be recv()'ed in the order
> that they were send()'ed when zeromq is configured with more "I/O"
> threads than the default.
>
> This is a little concerning: how increasing the number of threads
@Brett: You wrote:
> Not reliability per se but messages will not be recv()'ed in the order
> that they were send()'ed when zeromq is configured with more "I/O"
> threads than the default.
This is a little concerning: how increasing the number of threads results in
out-of-order delivery, unless
Lei Jiang writes:
> Regarding the proxy() call marshalling should be light I totally agree.
> Though the project I'm working on
> is just hobby, in my job industry there are sometimes customers
> fussing about milli-second level delays.
Even over tcp://, ZeroMQ latency is measured in tenths of
Hi Brett,
Thanks for the links to the documentation! I actually read them before but
should have read them more carefully. However, neither stated clearly what
the routing ID pattern is like. The man page says " one or more *routing id*
parts, *delimiter* part, one or more *body parts*". I guess
Lei Jiang writes:
> While putting together my code, I find it a bit hard to keep the
> implementation simple and efficient. For
> example, the routing IDs are separated by empty frames as delimiters.
> According to some charts in the guide,
> multiple IDs could be separated by multiple
Hi Brett,
I managed to bridge 2 router sockets and get what I wanted. Basically the
code will preserve the mapping from the client's ID to the requester's ID
and, swap the client ID with the worker ID for the requests; and swap the
client ID back for the responses.
While putting together my
Lei Jiang writes:
> Looks like I need to understand the MDP in better detail. I will give
> current design another try before exploring the MDP/PPP. My current
> plan is to "game" the router socket to route to the peer I want. For
> that I will maintain my own mappings. A list of all peer
Thanks again Brett for the detailed reply!
Looks like I need to understand the MDP in better detail. I will give
current design another try before exploring the MDP/PPP. My current plan is
to "game" the router socket to route to the peer I want. For that I will
maintain my own mappings. A list of
Hi again,
Lei Jiang writes:
> The MDP pattern is very interesting but I can't use it in my case. I
> am aiming to share data and resources inside a process so can't go
> inter-process.
Like all ZeroMQ things, there is no need to choose the transport
mechanism when writing the code. You may
Thanks a lot for the quick and detailed reply Brett!
The MDP pattern is very interesting but I can't use it in my case. I am
aiming to share data and resources inside a process so can't go
inter-process. I'm also trying to maximize concurrency and minimize latency
so ideally as few hops as
Hi Lei,
I think what you describe matches the majordomo pattern (MDP).
https://zguide.zeromq.org/docs/chapter4/#Service-Oriented-Reliable-Queuing-Majordomo-Pattern
In that description of MDP, the request from a client includes a
"service name". The broker uses that name to route the request to
Hi,
I hope someone can kindly give me a point in the right direction.
What I want to achieve is to have a thread pool with a bunch of REP sockets
in each thread to handle requests. A ROUTER socket binds to the server
address:port. A DEALER socket binds to an inproc address. All REP sockets
15 matches
Mail list logo
