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@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org