On Mon, 2010-06-07 at 16:40 -0500, Corneliu Boac wrote:
> ...
> What you say makes sense and is a lot easier to implement.
> So you think the proposed changes should work and I can start
> implementing them?
As I said at the beginning, I don't know anything about the cluster
pmda, so my notion of "should work" should be interpreted against that
caveat.
> Any suggestions, tips, etc?
Something does not "feel right" about closing sockets as a signal
mechanism ... I would have thought that the protocol between the pmda
and the daemons could be extended to make it more synchronous on each
socket something like ...
pmda pdu daemon
connect
accept
<-config_req
->config
<-data update
->ack_ok The ack contains state change info
ok means no change
<-data update
->ack_ok
<-data update
->ack_new_config pmda wants daemon to get new config info
<-config_req
->config
<-data update
->ack_new_config
<-config_req
[now if pmda holds off sending the config pdu, the daemon has effectively
been stopped from pushing updates]
->config sometime later, let the daemon run again
I know you did not want to muck with this protocol, but I think making
this sort of change will give you a more robust implementation as the
sender always knows how long to wait and the receiver does not need to
do anything until a pdu is received.
|