[Top][All Lists]

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

Re: [RFC PATCH 0/5] mptcp support

From: Paolo Abeni
Subject: Re: [RFC PATCH 0/5] mptcp support
Date: Fri, 09 Apr 2021 11:55:07 +0200
User-agent: Evolution 3.36.5 (3.36.5-2.fc32)

On Fri, 2021-04-09 at 10:42 +0100, Daniel P. Berrangé wrote:
> On Fri, Apr 09, 2021 at 10:34:30AM +0100, Daniel P. Berrangé wrote:
> > On Thu, Apr 08, 2021 at 08:11:54PM +0100, Dr. David Alan Gilbert (git) 
> > wrote:
> > > From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
> > >   I had a quick go at trying NBD as well, but I think it needs
> > > some work with the parsing of NBD addresses.
> > 
> > In theory this is applicable to anywhere that we use sockets.
> > Anywhere that is configured with the QAPI  SocketAddress /
> > SocketAddressLegacy type will get it for free AFAICT.
> The caveat is any servers which share the problem of prematurely
> closing the listener socket that you fixed here for migration.

For the records, there is an alternative to that, based on a more
advanced and complex MPTCP configuration available only on even more
recent kernels. MPTCP can be configured to accept additional subflows
on a different listener, which will be managed (created and disposed)
by the kernel with no additional user-space changes (beyond the MPTCP

That will require also a suitable firewalld (if enabled) configuration
(keeping the additional port open/accessible from the client).

Finally such configuration can be even more complex e.g. the additional
listener could be alternatively configured on the client side (!!!) and
the server could be configured to create additional subflows connecting
to such port (again no user-space changes needed, "only" more complex
MPTCP configuration).



reply via email to

[Prev in Thread] Current Thread [Next in Thread]