Re: [libvirt] [PATCH v2 01/12] Define keepalive protocol
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.
The server could probably deduce that the client supports keepalive from the
fact that the client calls remote_supports_feature(KEEPALIVE) but that seems
weak to me and sending a separate ADVERTISE message looks better :-)
Jirka