Advanced Request-Reply Patterns

Cours LUA Advanced Request-Reply Patterns, tutoriel & guide de travaux pratiques en pdf.

Advanced Request-Reply Patterns

In Chapter Two we worked through the basics of using ØMQ by developing a series of small
applications, each time exploring new aspects of ØMQ. We’ll continue this approach in this chapter, as we explore advanced patterns built on top of ØMQ’s core request-reply pattern.
We’ll cover:
• How to create and use message envelopes for request-reply.
• How to use the REQ, REP, DEALER, and ROUTER sockets.
• How to set manual reply addresses using identities.
• How to do custom random scatter routing.
• How to do custom least-recently used routing.
• How to build a higher-level message class.
• How to build a basic request-reply broker.
• How to choose good names for sockets.
• How to simulate a cluster of clients and workers.
• How to build a scalable cloud of request-reply clusters.
• How to use pipeline sockets for monitoring threads.

Request-Reply Envelopes

In the request-reply pattern, the envelope holds the return address for replies. It is how a ØMQ network with no state can create round-trip request-reply dialogs.
You don’t in fact need to understand how request-reply envelopes work to use them for common cases.
When you use REQ and REP, your sockets build and use envelopes automatically.When you write a device, and we covered this in the last chapter, you just need to read and write all the parts of a message.
ØMQ implements envelopes using multi-part data, so if you copy multi-part data safely, you implicitly copy envelopes too.
However, getting under the hood and playing with request-reply envelopes is necessary for advanced request-reply work. It’s time to explain how the ROUTER socket works, in terms of envelopes:
• When you receive a message from a ROUTER socket, it shoves a brown paper envelope around the message and scribbles on with indelible ink, « This came from Lucy ». Then it gives that to you. That is, the ROUTER gives you what came off the wire, wrapped up in an envelope with the reply address on it.
• When you send a message to a ROUTER, it rips off that brown paper envelope, tries to read its own handwriting, and if it knows who « Lucy » is, sends the contents back to Lucy. That is the reverse
process of receiving a message.
If you leave the brown envelope alone, and then pass that message to another ROUTER (e.g. by sending to a DEALER connected to a ROUTER), the second ROUTER will in turn stick another brown envelope on it, and scribble the name of that DEALER on it.
The whole point of this is that each ROUTER knows how to send replies back to the right place. All you need to do, in your application, is respect the brown envelopes. Now the REP socket makes sense. It carefully slices open the brown envelopes, one by one, keeps them safely aside, and gives you (the application code that owns the REP socket) the original message. When you send the reply, it re-wraps the reply in the brown paper envelopes, so it can hand the resulting brown package back to the ROUTERs down the chain.
Here now is a more detailed explanation of the four socket types we use for request-reply patterns:
• DEALER just deals out the messages you send to all connected peers (aka « round-robin »), and deals in (aka « fair queuing ») the messages it receives. It is exactly like a PUSH and PULL socket combined.
• REQ prepends an empty message frame to every message you send, and removes the empty message frame from each message you receive. It then works like DEALER (and in fact is built on DEALER) except it also imposes a strict send / receive cycle.
• ROUTER prepends an envelope with reply address to each message it receives, before passing it to the application. It also chops off the envelope (the first message frame) from each message it sends, and uses that reply address to decide which peer the message should go to.
• REP stores all the message frames up to the first empty message frame, when you receive a message and it passes the rest (the data) to your application.When you send a reply, REP prepends the saved envelopes to the message and sends it back using the same semantics as ROUTER (and in fact REP is built on top of ROUTER), but matching REQ, imposes a strict receive / send cycle.
REP requires that the envelopes end with an empty message frame. If you’re not using REQ at the other end of the chain then you must add the empty message frame yourself.
So the obvious question about ROUTER is, where does it get the reply addresses from? And the obvious answer is, it uses the socket’s identity. As we already learned, if a socket does not set an identity, the ROUTER generates an identity that it can associate with the connection to that socket(Figure 3-3).

1. Basic Stuff
1.1. Fixing the World
1.2. ØMQ in a HundredWords
1.3. Some Assumptions
1.4. Getting the Examples
1.5. Ask and Ye Shall Receive
1.6. A Minor Note on Strings
1.7. Version Reporting
1.8. Getting the Message Out
1.9. Divide and Conquer
1.10. Programming with ØMQ
1.11. Getting the Context Right
1.12.Making a Clean Exit
1.13.Why We Needed ØMQ
1.14. Socket Scalability
1.15.Missing Message Problem Solver.
1.16. Upgrading from ØMQ/2.2 to ØMQ/3.2
1.17.Warning – Unstable Paradigms!
2. Intermediate Stuff
2.1. The Zen of Zero
2.2. The Socket API
2.3. Plugging Sockets Into the Topology
2.4. Using Sockets to Carry Data
2.5. Unicast Transports
2.6. ØMQ is Not a Neutral Carrier
2.7. I/O Threads
2.8. Limiting Socket Use.
2.9. Core Messaging Patterns
2.10. High-level Messaging Patterns
3. Advanced Request-Reply Patterns
3.1. Request-Reply Envelopes
3.3. ROUTER-to-DEALER Routing
3.5. Address-based Routing
3.7. A High-Level API for ØMQ.
3.8. Asynchronous Client-Server
3.9.Worked Example: Inter-Broker Routing
4. Reliable Request-Reply 
4.1.What is « Reliability »?
4.2. Designing Reliability
4.3. Client-side Reliability (Lazy Pirate Pattern)
4.4. Basic Reliable Queuing (Simple Pirate Pattern)
4.5. Robust Reliable Queuing (Paranoid Pirate Pattern)
4.6. Heartbeating
4.8. Service-Oriented Reliable Queuing (Majordomo Pattern)
5. Advanced Publish-Subscribe 
5.1. Slow Subscriber Detection (Suicidal Snail Pattern).
5.2. High-speed Subscribers (Black Box Pattern)
5.3. A Shared Key-Value Cache (Clone Pattern)
5.4. The Espresso Pattern
6. The Human Scale..
6.1. The Tale of Two Bridges
6.2. Code on the Human Scale
6.3. Psychology of Software Development
6.4. The Bad, the Ugly, and the Delicious
6.5. Message Oriented Pattern for Elastic Design
6.6. Unprotocols..
6.7. Serializing your Data
6.8. Transferring Files
6.9. Heartbeating.
6.10. State Machines
6.11. Authentication using SASL