From: bkc@omnigate.clarkson.edu (Brad Clements)
Newsgroups: comp.infosystems.gopher
Subject: Comments about Gopher+
Date: 17 Aug 92 17:32:04 GMT
Distribution: comp

I have a few suggestions for the Gopher+ docs and concept. Hopefully not
too late.

1. The document should specify a maximum selector string length. All the docs
   say is that it could be more than 256 chars, but no maximum is given. This
   should be stated explicitely.

   Also, the max line length of an ABSTRACT return block should also be stated.

2. The VIEWS return value seems complicated. I don't think its necessary
   to have the < > around the value. It requires extra parsing to get out of
   the way. Also, I think the returned value should be in decimal octects,
   not K.

   Sure, I know, just multiply by 1024, but its not overly clear and the
   server will most likely know the exact size anyway. 


3. A + in the selector allows the server to return the data in three
   ways,   +count<CR><LF>DATA, or +-<CRLF><DATA><CRLF>.<CRLF>
   or dump and close the connection.

   Does this imply that the Gopher+ protocol will allow the TCP connection
   to stay open after the data is returned? If not, then there isn't any
   point in offering the DATA <CR>.<CR> return mode.

   A month ago I suggested that you allow the server to keep the connection
   open if it so desires. I received no reply from that suggestion, not even
   a reason as to why it wasn't acceptable.

   As previously stated, non-local internet connections take longer to start
   up due to the fixed transmissions used during the initial three-way shake.

   Also, depending on how the server is structured, new TCP connections
   can cause excessive overhead and limit the effective TPS 
   (transactions per second)

   For example, the unix gopherd executes a fork() on every connection.

   This is expensive in terms of system overhead. If a server were allowed
   to keep a connection open after returning the data, then the next
   request from the same connection could be answered immediately without
   the overhead of a fork.

   I'm not asking for state data to be kept, just allow additional requests
   to come in after the previous request has been answered. In fact
   changing the return value of do_command() in gopherd.c to non-zero
   and making sure there's a select() in readline() should do the
   trick.

   I think this would be a good thing for Gopher+ to support in clients
   and servers.

   Servers could still have an idle timeout (which they probably have
   to have anyway, even in the existing code). They can close the connection
   anytime between transactions. Clients can detect this easily and re-open
   if they have to.

   Consider a user wanting to retrieve a text file thats nested 5 levels deep
   on a single server (not an uncommon request). Thats 6 forks() and 6 new
   TCP connections where one is sufficient.

   Its a simple change, whose support is hinted at in the Gopher+ proposal.

   I'd like it to become part of the spec. 

I'd appreciate hearing at least an acknowledgement of receipt this time..


| Brad Clements, CCP     bkc@omnigate.clarkson.edu
| Sr. Network Engineer   Clarkson University              (315)268-2292