Hello, On Fri, 2021-04-09 at 10:10 +0100, Daniel P. Berrangé wrote: > On Thu, Apr 08, 2021 at 08:11:58PM +0100, Dr. David Alan Gilbert (git) wrote: > > From: "Dr. David Alan Gilbert" <dgilb...@redhat.com> > > > > Delay closing the listener until the cleanup hook at the end; mptcp > > needs the listener to stay open while the other paths come in. > > So you're saying that when the 'accept(2)' call returns, we are only > guaranteed to have 1 single path accepted,
when accept() returns it's guaranteed that the first path (actually subflow) has been created. Other subflows can be already available, or can be created later. > and the other paths > will be accepted by the kernel asynchronously ? Hence we need to > keep listening, even though we're not going to call accept(2) again > ourselves ? Exactly, the others subflows will be created by the kernel as needed (according to the configuration and the following MPTCP handshakes) and will _not_ be exposed directly to the user-space as additional fds. The fd returned by accept() refers to the main MPTCP socket (that is, the "aggregated" entity), and not to some specific subflow. Please let me know if the above clarifies in some way. Thanks! Paolo
