[RFC] ct_sync 0.15 (corrected)
Thu Aug 19 13:13:51 CEST 2004
2004-08-19, cs keltez=E9ssel 13:06-kor Harald Welte ezt =EDrta:
> > On the other hand, it may be possible that the master is not
> > able to re-send the packet, for example this may be the case =
> > it is "too old", and is not present in the backlog anymore. I=
> > this case, the slave should be notified that recovery is not
> > possible this way, and it needs to do a full re-sync.
> Within the current protocol, the master can just make that decision and
> do a full resync without telling the slave.
Indeed. However, I'd like to implement a new state (SLAVE_BROKEN)
later, which could be used to avoid electing a slave as new master if
that node is known to be not in sync. A facility of this kind would help
in early detection of such cases.
> > 3. There are a few things in the connection tracking code which
> > are incompatible with replication "by design". For example,
> > the expectfn() function in the expectation structure is such:
> > simply, there is no way to replicate a stand-alone function
> > pointer which could point to any arbitrary function.=20
> Yes, indeed. we could look up the symbol name in the symbol table and
> replicate that ;) Crude hack, but it would work.
Unfortunately I don't think it would work... AFAIK there is no symbol
table information in 2.4 kernels and usually these functions are
declared as static anyway. Moreover, take a look at the H.323 helper, it
uses this expectfn function to set the helper of the conntrack to an
unregistered helper structure... I think there is no point in making
ct_sync overly complicated; these helpers should be fixed instead. (I
don't know why the H.323 does things this way, but it is completely
hopeless to replicate things like this.)
> > One more example could be TCP window tracking, I don't think we
> > have the necessary bandwidth and CPU time to send an update
> > message after each and every received TCP packet... Any idea
> > how we could solve these problems?
> We already do this since the timeout is updated with every packet. So
> at this point, I see not much difference. Jozsef and I agreed some tim=
> in the past, that if we don't replicate all the window information, in
> the event of a slave being propagated to master, the new master should
> disable windowtracking or switch into a lazy mode.
Indeed, the timeout is updated with every packet. However, we do not
generate an update message for IPCT_REFRESH events at the moment. On the
other hand, we replicate the timeout changes when a state change occurs
as well, so I don't worry about incorrect (relative) timeout values at
Anyway, thanks for the comments.
More information about the netfilter-devel