Received: with ECARTIS (v1.0.0; list gopher); Wed, 20 Mar 2002 20:11:04 -0500 (EST) Return-Path: Delivered-To: gopher@complete.org Received: from christoph.complete.org (pcp947166pcs.cstltn01.in.comcast.net [68.58.145.248]) by pi.glockenspiel.complete.org (Postfix) with ESMTP id 051DD3B81F for ; Wed, 20 Mar 2002 20:11:04 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by christoph.complete.org (Postfix) with ESMTP id 604E95A3EE for ; Wed, 20 Mar 2002 20:11:04 -0500 (EST) Date: Wed, 20 Mar 2002 20:11:04 -0500 Subject: [gopher] Re: \n.\n Content-type: text/plain; charset=US-ASCII Mime-Version: 1.0 (Apple Message framework v481) From: John Goerzen To: gopher@complete.org Content-Transfer-Encoding: 8bit In-Reply-To: Message-Id: <83DC469D-3C68-11D6-B325-0003930BF072@complete.org> X-Mailer: Apple Mail (2.481) X-archive-position: 519 X-ecartis-version: Ecartis v1.0.0 Sender: gopher-bounce@complete.org Errors-to: gopher-bounce@complete.org X-original-sender: jgoerzen@complete.org Precedence: bulk Reply-to: gopher@complete.org List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-ID: Gopher X-List-ID: Gopher List-subscribe: List-owner: List-post: List-archive: X-list: gopher On Wednesday, March 20, 2002, at 04:51 PM, Robert Hahn wrote: > I would fully support this if you can explain to me how a gopher > client is supposed to 'know' when the end of a file is and closes the > connection. Well, this capability is built into the TCP implementation of the operating system. Specifically, to read data from the network, you use the read(2) system call. This system call returns a code indicating how much data was actually available to read -- or a code indicating that the other side has finished transmitting and has closed the connection (among others). A client can simply use the return value from read() to figure out when the file is finished. Note that other protocols such as HTTP/1.0 and FTP (data) work exactly this way. So, \n.\n is not really needed at all in gopher. -- John