From owner-freebsd-hackers Sat Nov 16 14:44:38 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA24974 for hackers-outgoing; Sat, 16 Nov 1996 14:44:38 -0800 (PST) Received: from quagmire.ki.net (root@quagmire.ki.net [205.150.102.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id OAA24940 for ; Sat, 16 Nov 1996 14:44:24 -0800 (PST) Received: from localhost (scrappy@localhost) by quagmire.ki.net (8.8.2/8.7.5) with SMTP id RAA08720; Sat, 16 Nov 1996 17:44:27 -0500 (EST) Date: Sat, 16 Nov 1996 17:44:27 -0500 (EST) From: "Marc G. Fournier" To: Jonathan Lemon cc: hackers@FreeBSD.org Subject: Re: Hate to ask more about sockets...but... In-Reply-To: <199611162211.WAA05401@right.PCS> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk On Sat, 16 Nov 1996, Jonathan Lemon wrote: > > Great, this works...sort of. For some reason, the program reports that the > > read completed correctly, with the exact number of bytes read as I wrote to > > the socket, but I'm missing several lines out of the graphic when I view it. > > (check out http://www.ki.net/~scrappy/test.html, if you want to see what I > > mean by "missing several lines") > > > > If I change 'cnt' in the server to be 2 instead of 1, the graphic will come > > out completely...as if, for some reason, the last read didn't get written to > > the screen if it only 'scans' the file once. > > > > The other thing I found was weird was that if I changed the 'break' in > > the client side to a 'continue', so that it continued to scan the input > > socket for data (ie. await the next image to be send down the socket), I > > lost even more data from the image. > > It sounds almost if your client is buffering it's output writes, and that > you aren't flushing the buffer before the client exits. I cobbled up a quick > client/server example with the above code, and it doesn't seem to have any > problems transferring data back and forth. (e-mail me if you want the code). One of the things I thought about after sending out the original is that since it is a blocked read, that the last packet, which is <4096, is taking too long to return...I'm going to attempt making it a non-blocking read instead, and see if that fixes the problem. It always seems to be the last read that goes missing... Marc G. Fournier scrappy@ki.net Systems Administrator @ ki.net scrappy@freebsd.org