Handshaking

Handshaking 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 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.^[15] 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.

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 I’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 handshaking at a relatively small expense to the service.

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 SLAs, 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. Your best bet is to build handshaking into any custom protocols that you implement.

Circuit Breaker is a stopgap you can use when calling services that cannot handshake. In that case, instead of asking politely whether the server can handle the request, you 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.

Remember This

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 your own low-level protocols.

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.