Sorry for the late reply. Yes, I agree. There are these two theories. My experience seems to be that you are more likely (in practice) to hit the first method (in which the new SYN is actually a new one and not an old SYN hanging out in the network somewhere). There could be scenarios in which that might happen though, ofcourse. Perhaps, this behaviour should be configurable/sysctable ?? Rajeev ----- Original Message ----- From: "Andi Kleen" <ak@suse.de> To: "Rajeev Bector" <rajeev@akamai.com> Cc: "Andi Kleen" <ak@suse.de>; <kuznet@ms2.inr.ac.ru>; <linux-net@vger.rutgers.edu> Sent: Tuesday, July 11, 2000 3:19 AM Subject: Re: multiple TCP sockets with same (srcip,dstip,sport,dport) | On Mon, Jul 10, 2000 at 01:02:21PM -0700, Rajeev Bector wrote: | > Hi Andi, | > Thanks for your patch. If I am not wrong, it seems to have two | > problems: | > | > [1] If the new SYN is out of window, we do send an ACK back but | > we dont update the open_req's rcv_isn. | > | > [2] If its in the window, we decide to send a RST which is fine, | > but we need to free the open_req structure. | > | > Does that seem right ? | | You can have two theories about the origin of the different SYNs. | Either the host has been rebooted/the address has been redialed | and the new SYN is from the new owner of the address, or it is an | old duplicated segment in the network that is not from the owner | of the source address. You seem to prefer the first way. I and the | RFC consider it the second way. If you believe in the new owner | fully you wouldn't send RST but silently rewrite the open_request. | I think it is more clean to not let new SYNs rewrite open_requests. | | | | -Andi - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.rutgers.edu
