Can anyone explain the request-reply broker zeromq example?
Asked Answered
C

2

6

I'm refering to the 'A Request-Reply Broker' in the Zeromq documentation: http://zguide.zeromq.org/chapter:all

I'm getting the general gist of the app: it acts like an intermediary and routes messages from the client to the server and back again.

What I'm not getting though is how it makes sure the correct response from a server is sent to the correct client which originally made the request. I don't see anything in the code example which makes sure about this.

Now in the example they only send 1 message (hello) and 1 response (world), so even if messages are mixed up it doesn't matter, but I'm guessing that the testclient and server are kept deliberately simple.

Any thoughts are welcome...

Champaign answered 6/12, 2010 at 20:18 Comment(0)
O
9

All zeromq sockets implicitly have an identity associated with them. (You can obtain this identity with zmq_getsockopt().)

For bi-directional socket types not XREQ or XREP, this identity is automatically transferred as part of every message sent over the socket. The REP socket uses this identity to route the response message back to the appropriate socket. This has the effect of automatic routing.

Under the hood, identities are transferred via multipart messages. The first message in a multipart message will contain the socket identity. An empty message will follow, followed by all messages specified by the user. The REQ and REP sockets deal with these prefixed messages automatically. However, if you are using XREQ or XREP sockets, you need to populate these identity messages yourself.

If you search for "identity" on the ZMQ Guide, you should find all the details you will ever want to know about how identities and socket routing works.

Overdone answered 25/4, 2011 at 21:26 Comment(0)
C
1

Ok in chapter 3 they all of a sudden explain that there is an underlying concept of an 'envelope' which the req/resp pattern invisubly uses.

This explains how it works.

Champaign answered 6/12, 2010 at 21:38 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.