Received: with ECARTIS (v1.0.0; list gopher); Wed, 20 Mar 2002 20:11:04 -0500 (EST) Return-Path: <jgoerzen@complete.org> 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 <gopher@complete.org>; 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 <gopher@complete.org>; 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 <jgoerzen@complete.org> To: gopher@complete.org Content-Transfer-Encoding: 8bit In-Reply-To: <p05010404b8beb412dd09@[205.189.158.32]> 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: <mailto:ecartis@complete.org?Subject=help> List-unsubscribe: <mailto:gopher-request@complete.org?Subject=unsubscribe> List-software: Ecartis version 1.0.0 List-ID: Gopher <gopher.complete.org> X-List-ID: Gopher <gopher.complete.org> List-subscribe: <mailto:gopher-request@complete.org?Subject=subscribe> List-owner: <mailto:jgoerzen@complete.org> List-post: <mailto:gopher@complete.org> List-archive: <http://www.complete.org/mailinglists/archives/> 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