|
Hello,
On Sun, 6 Aug 2000, Ratz wrote:
> Hi Wensong,
>
> I've been thinking about our talk at OLS on a possible
> kernel-2-kernel masq table syncing (kmasqsd) design.
>
> To recall:
> We decided to implement a kernel daemon like
> kflushd that would periodically send new connection
> template entries from the master director to the
> backup (blaster) over a dedicated heartbeat based
> on UDP packets. This is a good basic concept, however,
> I'suggest not to send the updates via UDP but rather
> define a own easy protocoll and run it over the
> parallel port, since this needs no IP-stack
> processing and will also work if there is a stack
> problem. And in case of a failover and a shutdown
> of the interfaces, the daemon could still sync
> without being interupted and so providing to
> best syncing state. The amount of lost connections
> would definitely very small, if not even zero.
>
> Just a thought ...
> Suggestions, flames :) ?
Questions:
- what is the main goal? Some things are not "possible" to
implement.
- is breaking the current connections fatal? 1 to 5 seconds
without director before switching to backup one?
- are we going to replicate each state change or to grab a
connection table snapshot?
- is there a requirement for the used transport? Can this
transport be universal, i.e. export data to user space daemon
and then send the data using any type of transport?
- Is it required the remote director to be with same CPU type
if we send binary data?
- What can be the time to replicate 128MB connection table? 1 second,
1 minute? What is the acceptable time?
>
> best regards,
> Roberto Nibali, ratz
Regards
--
Julian Anastasov <ja@xxxxxx>
|
