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@xxxxxxxxxx +1-801-349-2682
Libvirt virtualization library http://libvirt.org
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list