Learn how to architect, design, and build distributed systems for the real world.

Become a Distributed Systems Professional

In this module, we will examine ways to architect, design, and build software—particularly distributed systems.. This module is designed to prepare us for unpredictable users who might be a potential threat to our softwares. Our software will be under attack from the moment it is released. It needs to stand up to flash mobs or DDoS attacks by poorly secured IoT toaster ovens. We’ll examine  a software that failed the test and find ways to ensure our software survives contact with the real world.

Distributed Systems: Building Software for the Real World

# What is handshaking?
**Handshakin**g refers to signaling between devices that regulate communication between them. Serial protocols such as `EIA-232C` (formerly known as `RS-232`) rely on the receiver to indicate when it’s ready to receive data. Analog modems used a form of handshaking to negotiate a speed and a signal encoding that both devices would agree upon. And, as illustrated earlier in the three-phase handshake, TCP uses a three-phase handshake to establish a socket connection. TCP handshaking also allows the receiver to signal the sender to stop sending data until the receiver is ready. 


## Handshaking with HTTP
Handshaking is ubiquitous in low-level communications protocols but is almost nonexistent at the application level.
The sad truth is that HTTP isn’t good at shaking hands. HTTP-based protocols, such as `XML-RPC` or `WS-I Basic`, have few options available for handshaking. HTTP provides a response code of `“503 Service Unavailable”` which is defined to indicate a temporary condition [$^{2}$](https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html). 
## Error codes
Most clients, however, will not distinguish Most clients, however, will not distinguish between different response codes. If the code is not a `“200 OK"`, `“403 Authentication Required"`, or `“302 Found (redirect)"`, the client probably treats the response as a fatal error. Many clients even treat other 200 series codes as errors!
Similarly, the protocols beneath every remote procedure call technology (CORBA, DCOM, Java RMI, and so on) are equally bad at signaling their readiness to do business.
## Partnership between load balancer and application server
Handshaking is all about letting the server protect itself by throttling its own workload. Instead of being victim to whatever demands are made upon it, the server should have a way to reject incoming work. The closest approximation we’ve been able to achieve with HTTP-based servers relies on a partnership between a load balancer and the web or application servers. The web server notifies the load balancer, which is pinging a health check page on the web server periodically, that it is busy by returning either an error page (HTTP response code `503 “Not Available”` works) or an HTML page with an error message. The load balancer then knows not to send any additional work to that particular web server.

Of course, this helps only for web services and still breaks down if all the web servers are too busy to serve another page.
When there are several services, each can provide a health check query for use by load balancers. The load balancer would then check the health of the server before directing a request to that instance. This provides good hand-shaking at a relatively small expense to the service.
## Handshaking and load balancer
Handshaking can be most valuable when unbalanced capacities are leading to slow responses. If the server can detect that it will not be able to meet its **service level agreements (SLA)**, then it should have some means to ask the caller to back off. If the servers are sitting behind a load balancer, then they have the binary on/off control of stopping responses to the load balancer, which would in turn take the unresponsive server out of the pool. This is a crude mechanism, though. The best bet is to build handshaking into any custom protocols that are implemented.

## Circuit breakers
Circuit Breaker is a stopgap we can use when calling services that cannot handshake. In that case, instead of asking politely whether the server can handle the request, just make the call and track whether it works. 

Overall, handshaking is an underused technique that could be applied to great advantage in application-layer protocols. It is an effective way to stop cracks from jumping layers, as in the case of a cascading failure.

# Tips to remember
## Create cooperative demand control
Handshaking between a client and a server permits demand throttling to serviceable levels. Both the client and the server must be built to perform handshaking. Most common application-level protocols do not perform handshaking.
## Consider health checks
Use health checks in clustered or load-balanced services as a way for instances to handshake with the load balancer.
## Build handshaking into low-level protocol
If you create your own socket-based protocol, build handshaking into it so that the endpoints can each inform the other when they are not ready to accept work.

Learn about analog modems, three-phase handshake, handshake with HTTP, error codes, load balancers, and circuit breakers.