On Wed, Nov 18, 2015, at 16:32, Hannes Frederic Sowa wrote: > On Wed, Nov 18, 2015, at 16:16, Eric Dumazet wrote: > > On Wed, 2015-11-18 at 15:56 +0100, Hannes Frederic Sowa wrote: > > > On Wed, Nov 18, 2015, at 15:45, Lorenzo Colitti wrote: > > > > On Wed, Nov 18, 2015 at 10:31 PM, Hannes Frederic Sowa > > > > <han...@stressinduktion.org> wrote: > > > > > I was not saying using tcp_close literally, sorry for not making that > > > > > clear, but just model the state transitions after tcp_close. At least > > > > > it > > > > > seems like a normal close to me. > > > > > > > > But it shouldn't be a normal close. Consider calling SOCK_DESTROY on a > > > > socket that is streaming data to a peer. If SOCK_DESTROY results in > > > > the kernel sending a FIN, the remote side might think that the sender > > > > closed the connection gracefully, even though the local side aborted > > > > the connection. > > > > > > Oh, yes, I understand. The connection wasn't closed by the application > > > but by the administrator forcefully. So we should never indicate a > > > successful TCP shutdown with FIN but with RST. A TIME_WAIT period > > > actuallty still seems useful to me, maybe with different semantics, only > > > RST incoming data? > > > > There is some confusion. > > > > TIME_WAIT are used to be able to send ACK packets to incoming valid > > packets. > > I was only talking to prevent fast address/port reuse on the same socket > and preventing delayed packets being accepted by a
sorry... accepted by a later connection reusing the same quadrupel. Bye, Hannes -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
