[rabbitmq-discuss] Connecting over a highly unreliable connection

Matthias Radestock matthias at lshift.net
Tue Nov 11 15:44:04 GMT 2008


Gavin Bong wrote:
> In any case, what's the actual definition of the heartbeat parameter ?
> Does it mean that we expect some packets to roundtrip or replies to
> come back in that duration ?

Here is the current draft of the heartbeat logic taken from the upcoming 
AMQP 0-9-1 spec:


Heartbeat frames tell the recipient that the sender is still alive.  The 
rate and timing of heartbeat frames is negotiated during connection tuning.

Guidelines for implementers:
- Heartbeat frames MUST have a channel number of zero.  A peer that 
receives an invalid heartbeat frame MUST raise a connection exception 
with reply code 501 (frame error).

- If the peer does not support heartbeating it MUST discard the 
heartbeat frame without signalling any error or fault.

- The client should start sending heartbeats after receiving a 
Connection.Tune method, and start monitoring heartbeats after receiving 
Connection.Open.  The server should start sending and monitoring 
heartbeats after receiving Connection.Tune-Ok.

- The peer should make a best effort to send heartbeats at specified 
intervals. Heartbeats can be sent at any time. Any sent octet is a valid 
substitute for a heartbeat, thus heartbeats only have to be sent if no 
non-heartbeat AMQP traffic is sent for longer than one heartbeat 
interval. If a peer detects no incoming traffic (i.e. received octets) 
for two heartbeat intervals or longer, it should close the connection 
without following the Connection.Close/Close-Ok handshaking, and log an 

- Heartbeating should continue until the connection socket is closed, 
including during and after Connection.Close/Close-Ok handshaking.




More information about the rabbitmq-discuss mailing list