[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[Linux-cluster] New, improved csnap-agent checked in

This version of csnap-agent borrows the server template from csnap.c to 
accept and serve multiple local connections from cluster devices.  So 
only a single named socket is needed for all csnap devices on a node 
connecting to the same snapshot server.

The snapshot agent also needs to communicate with other cluster 

  - Connection manager and/or resource manager, to request a snapshot
    server connection

  - Resource manager may request that the snapshot agent start a
    snapshot server.

The same polling harness can handle this other traffic easily enough.  
The question is, should those other components be taught to make their 
connections to the named socket, in which case we get to reuse the 
connection code as well?  Should our csnap agent take it upon itself to 
connect to those other components, or should it make its socket name 
known and wait for connections?  The latter makes our code smaller, but 
is it right?

If we use the named socket for connection with other components, the 
implication is that we will only communicate with local agents of those 
components.  On the other hand, if we use inet connections, we then 
have to teach the csnap agent how to fail the connections over, which 
really seems like somebody else's job.

I dunno.  A reasonable next step is to manually feed the csnap agent 
some csnap server addresses over a pipe instead of, or in addition to, 
taking a server address on the command line the way it does now.  This 
will allow us to test server failover, at least the flavor of server 
failover that doesn't need to consult the connection manager.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]