|
On 金, 8月 22, 2008 at 07:29:50午前 +1000, Simon Horman wrote:
> On Thu, Aug 21, 2008 at 11:59:44AM +0200, Julius Volz wrote:
> > On Thu, Aug 21, 2008 at 3:17 AM, Simon Horman <horms@xxxxxxxxxxxx> wrote:
> > > On Wed, Aug 20, 2008 at 06:15:07PM +0200, Julius Volz wrote:
> > >> What is not supported with IPv6:
> > >> - handling fragmentation or other extension headers
> > >> - FTP application helper (can be loaded, but only operates on v4)
> > >> - sync daemon (can be started, but only operates on v4)
> > >
> > > Other than the packet format of the sync deamon, are there any
> > > fundamental restrictions here? If we extended the sync daemon,
> > > could it work? If so, perhaps we could rev the sync deamon protocol
> > > and fix a few other kinks, like the handling of timeouts and the
> > > general lack of extendability, at the same time.
> >
> > There shouldn't be any fundamental restrictions, it's just a piece of
> > the puzzle that I could easily leave out of the picture for now.
> >
> > I haven't studied the sync daemon closely yet, but one thing I was
> > briefly wondering about was whether we should just blow up the
> > addresses in struct ip_vs_sync_conn to be of type union nf_inet_addr
> > (probably not acceptable, wasting too much bandwidth for v4 entries)
> > or how to send differently sized entries based on the IP version in a
> > clean way. But it sounds like you'd want to redesign a lot of that
> > anyways? I'm glad to help with anything, I just don't know this code
> > as well as you or Sven, but I'll study it more. Maybe you can share
> > some ideas on the extensibility you want to see?
>
> What I was thinking is that any change
Sorry, I forgot to finish this sentance :-(
What I was thinking was that any change would introduce a
protocol incompatibility. However I think that there is
some room for small changes to be added using currently unsued
bits in ip_vs_sync_conn.flags. This could also be used to
allow syncryonising of timeouts (which is unrelated to IPv6).
So while my general feeling that the synchronisation protocol
is not as extendable as it should be stands. We can probably
work with the current protocol for now.
--
To unsubscribe from this list: send the line "unsubscribe lvs-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
|
