1. ZeroMQ Chapter 4 Reliable Request-Reply Patterns
Kieun Seong

2. Contents Definition and Design of Reliability
Types of Reliable Request-Reply Patterns
The Lazy Pirate pattern
The Simple Pirate pattern
The Paranoid Pirate pattern
The Majordomo pattern
The Binary Star pattern
The Freelance pattern

3. Definition and Design of Reliability
Related with terms of failure
Keeping things working properly when code freezes or crashes
Among 3 patterns, focus on request-reply pattern

4. The Lazy Pirate Pattern
Client side reliability
Resend a request, if no reply has arrived within a timeout period
Abandon the transaction if there is still no reply after several requests

5. Lazy Pirate Client Code

6. Lazy Pirate Client Code

7. Lazy Pirate Server Code

8. The Simple Pirate Pattern
Extends the Lazy Pirate pattern with a queue proxy that lets us talk to multiple servers(workers).

9. Simple Pirate Worker Code

10. Simple Pirate Worker Code

11. Simple Pirate Load Balancer Code
frontend
backend

12. Simple Pirate Load Balancer Code
frontend
backend

13. The Paranoid Pirate Pattern
Simple Pirate is not robust when a queue crash
The queue does not detect worker failure
Use Heart beating

14. Heartbeating
Solves the problem of knowing whether a peer is alive or dead
One Way Heartbeats
Sending a heartbeat message from each node to its peers, if one node hears nothing from another it will treat that peer as dead
Inaccurate when sending large amounts of data

15. The Majordomo Pattern Improve version of Paranoid Pirate Pattern
Adds a service name to requests
Service oriented broker
Workers are registered for specific services
Synchronous / Asynchronous Major Pattern

16. Synchronous and Asynchronous Majordomo
Socket Type
REQ
DEALER
Function
Send
Send and Receive
Retry Request 3
None

17. Synchronous Majordomo Client Code

18. Asynchronous Majordomo Client Code
MSG_
SENDER
Empty
MDPC_ xy
Service
Name
Message
Client “”
CLIENT
“echo”
“Hello world”

19. Majordomo Worker Code
It’s a little misnamed since it first sends any reply and then waits for a new request. Send reply, if any, to broker and wait for next request.

20. Majordomo Worker API : connect to broker
MSG_
SENDER
Empty
MDPW_ xy
Command
Service
Name
Worker “”
WORKER
READY
“echo”

21. Majordomo Broker Code
In s_broker_bind function, use a single socket for both clients and workers
MSG_
SENDER
Empty
MDPW_ xy
Command
Service
Name
Worker “”
WORKER
READY
“echo”
MSG_
SENDER
Empty
MDPC_ xy
Service
Name
Message
Client “”
CLIENT
“echo”
“Hello world”

22. Majordomo Broker Code MSG_ SENDER Empty MDPW_ xy Command Service Name
Worker “”
WORKER
READY
“echo”
MSG_
SENDER
Empty
MDPC_ xy
Service
Name
Message
Client “”
CLIENT
“echo”
“Hello world”

23. The Binary Star Pattern
2 servers in a primary–backup pair
Primary : the server that is normally or initially ‘active’
Backup : the server that is normally ‘passive’. It will become active when the primary server disappears from the network, and the client applications ask the backup server to connect.

24. The Freelance Pattern Brokerless reliability Peer to peer architecture
Name service, to get reliability uses pool(any size but practically 2 would be enough)
Use DEALER sockets and blast out requests
Use ROUTER sockets so clients can address specific servers

25. Brutal Shotgun Massacre
Client use a DEALER socket
Clients approach
Connect to all servers
When we have request, blast it out as many time as we have servers
Wait for the first reply and take that
Ignore any other replies

26. Brutal Shotgun Massacre : Client Code
Request
“random name”