ZeroMQ Chapter 4 Reliable Request-Reply Patterns Kieun Seong

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

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

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

Lazy Pirate Client Code

Lazy Pirate Client Code

Lazy Pirate Server Code

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

Simple Pirate Worker Code

Simple Pirate Worker Code

Simple Pirate Load Balancer Code frontend backend

Simple Pirate Load Balancer Code frontend backend

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

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

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

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

Synchronous Majordomo Client Code

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

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.

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

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”

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”

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.

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

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

Brutal Shotgun Massacre : Client Code Request “random name”