From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <836e436c5d5dad6e4a07e45ab01ae80b@felloff.net> Date: Sun, 10 May 2015 22:19:56 +0200 From: cinap_lenrek@felloff.net To: 9fans@9fans.net In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] fossil+venti performance question Topicbox-Message-UUID: 50f8279e-ead9-11e9-9d60-3106f5b1d025 > * the SYN-ACK needs to send the local mss, not echo the remote mss. > asymmetry is "fine" in the other side, even if ip/tcp.c isn't smart enough to > keep tx and rx mss seperate. (scare quotes = untested, there may be > some performance niggles if the sender is sending legal packets larger than > tcb->mss.) that is what it already does as far as i can see. on the server side, we receive a SYN, put it in limbo and reply with SYN|ACK (sndsynack()) sending our local mss straight from tcpmtu(), no adjust. at this point heres no connection or tcb as everything is still in limbo. only once we receive the ACK, tcpincoming() gets called which pulls the info we got so far (including the mss sent by the client in the SYN pakcet) out of limbo and sets up a connection with its tcb. to summarize what happens on the server for incoming connection: 1.a) tcpiput() gets a SYN packet for Listening connection, calls limbo(). 1.b) limbo() saves the info (including mss) from SYN in limbo database and calls sndsynack(). 1.c) sndsynack() sends SYN|ACK packet with mss option set from tcpmtu() without any adjust. 2.a) tcpiput() gets a ACK packet for Listening connection, calls tcpincoming(). 2.b) tcpincoming() looks in limbo, finds lp. and makes new connection. 3.c) initialize our connections tcb->mss. > * the setting of tcb->mss in tcpincoming is not correct, tcp->mss is > set by SYN, not by ACK, and may not be reset. (see snoopy below.) you say we shouldnt initialize tcb->mss in 3.c and not use the mss from the initial SYN to adjust it. i dont understand why not as i dont see where it would be initialized otherwise. it appears that was what the initial patch from david was about to fix which made sense to me. as far as i can see, the procsyn() is unrelated to server side incoming connections. it only gets called on behalf of a client outgoing connect when the connection is in Syn_sent state and processes the SYN|ACK that was generated by the process descibed in 1.c above. -- cinap