[libvirt] [PATCH v2 01/12] Define keepalive protocol

[Eric Blake]

On 09/29/2011 07:46 AM, Jiri Denemark wrote:
> On Thu, Sep 29, 2011 at 14:19:43 +0100, Daniel P. Berrange wrote:
>> On Fri, Sep 23, 2011 at 10:24:46AM +0200, Jiri Denemark wrote:
>>> The keepalive program has three procedures: ADVERTISE, PING, and PONG.
>>> All are used only in asynchronous messages and the sender doesn't wait
>>> for any reply. However, the party which receives PING messages is
>>> supposed to react by sending PONG message the other party, but no
>>> explicit binding between PING and PONG messages is made. ADVERTISE is
>>> sent by a client to indicate it supports keepalive protocol. Server is
>>> not allowed to send any keepalive message until it sees ADVERTISE.
>>
>> I guess I'm not entirely understanding what the point of the
>> ADVERTISE message here is?
>>
>> IIUC, the flow of messages you are describing will end up as:
>>
>>   1. C ->  S  remote_supports_feature_args (KEEPALIVE)
>>   2. S ->  C  remote_supports_feature_ret  (TRUE|FALSE)
>>   3. C ->  S  keepalive ADVERTISE
>>   4. C ->  S  keepalive PING
>>   5. S ->  C  keepalive PONG
>>   6. C ->  S  keepalive PING
>>   7. S ->  C  keepalive PONG
>>   ...
>>   n. C ->  S  keepalive PING
>>   n+1. S ->  C  keepalive PONG
>>
>> We need to the remote_supports_feature method to determine if the
>> keepalive protocol is supported, what purpose is the ADVERTISE
>> message serving ?
>
> PING messages can be sent by both client and server and sending them can be
> independently disabled on both sides. ADVERTISE is sent because a server may
> never get any PING messages from a client which was configured not to send
> them. But the server still wants to know that the client supports this feature
> and thus the server can send PING messages. Also there is a keepalive timeout
> between ADVERTISE and PING, which can be different on both sides so server may
> decide to send PING earlier than the client.

So, if I understand correctly, there are two flows:

client->server pings:

virConnectAllowKeepAlive()
1. C ->  S  remote_supports_feature_args (KEEPALIVE)
2. S ->  C  remote_supports_feature_ret  (TRUE|FALSE)
virConnectStartKeepAlive()
4a. C ->  S  keepalive PING
5a. S ->  C  keepalive PONG
6a. C ->  S  keepalive PING
7a. S ->  C  keepalive PONG
...

server->client pings:

virConnectAllowKeepAlive()
1. C ->  S  remote_supports_feature_args (KEEPALIVE)
2. S ->  C  remote_supports_feature_ret  (TRUE|FALSE)
3. C ->  S  keepalive ADVERTISE
server checks conf file
4b. S ->  C  keepalive PING
5b. C ->  S  keepalive PONG
6b. S ->  C  keepalive PING
7b. C ->  S  keepalive PONG
...

Steps 1-3 are shared by both directions (although step 3 is not 
essential in the c->s direction).  Remaining ping/pong sequences are 
independent, and can operate at different frequencies (c->s at the 
frequency in virConnectStartKeepAlive(), and s->c at the frequency in 
the conf file).  Either side can terminate the connection if enough 
PONGs are not received (c->s terminates according to count in 
virConnectStartKeepAlive(), and s->c according to conf file).

-- 
Eric Blake   eblake at redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org