From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: * X-Spam-Status: No, score=1.3 required=5.0 tests=RDNS_NONE autolearn=no autolearn_force=no version=3.4.4 Received: (qmail 29682 invoked from network); 1 Sep 2021 01:29:22 -0000 Received: from unknown (HELO 4ess.inri.net) (216.126.196.42) by inbox.vuxu.org with ESMTPUTF8; 1 Sep 2021 01:29:22 -0000 Received: from duke.felloff.net ([216.126.196.34]) by 4ess; Tue Aug 31 21:20:22 -0400 2021 Message-ID: Date: Wed, 01 Sep 2021 03:20:10 +0200 From: cinap_lenrek@felloff.net To: 9front@9front.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: transactional encrypted markup SVG scripting realtime generator Subject: Re: [9front] rconnect via aan reliability patch Reply-To: 9front@9front.org Precedence: bulk > Write does not block. Read does. i know. > In the case with read errors, the aanserver end did everything > before aanclient starts to read the address, and somehow the channel > has hung up before the read. yeah, but we really need to figure out why. we might have a bug in the tcp stack here, or you might just have some mtu issues in your network. i'm not going to blindly change protocols to tamper over mysterious tcp connection problems. > The extra read in aanserver blocks the aanserver at that point and > wait for the OK signal from aanclient before continuing. yes, i understand that. > The thing I don't understand is that what actually makes the channel > hang up. Do you have any suggestions as to how to debug this issue? i never had these issues. is it reproducable for you? we can start by making packet captures with snoopy or wireshark. if it is sporadic, we could also try to provoke it by doing the exact opposite to your patch and delaying the client with a sleep maybe? it could also be possible that it is closed my ourselfs somehow by accident. -- cinap