Date: Mon, 17 Aug 92 14:33:04 CDT
From: fxa@boombox.micro.umn.edu ("Farhad Anklesaria" )
Original-To: bkc@omnigate.clarkson.edu
Original-Cc: gopher-news@news2.cis.umn.edu, gopher@boombox.micro.umn.edu
Subject: Re: Comments about Gopher+
Newsgroups: comp.infosystems.gopher
Distribution: comp

Hello Brad,

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

I'll add my $0.02 to Daniel...

> 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.

Thanks for that feedback...
We'll revise the original Gopher doc before freezing it very soon now.
And we'll remove the 256 char restriction (if any?) on selector length.
OK?  Gone.  The Gopher+ doc says nothing about 256 chars.

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

Hmm.  Treat it just like any other document.  No length mandates there...
although if it's longer than maybe 80, some clients will wrap, some will
not....  Do you want your stuff to look pretty over all platforms?
If so, it behooves you to respect the LCD: the 80 column glass TTY (vt100).

> 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.

There may be other stuff on the line too... eg.

     Text: Gets 90% of info. <45K>

Users like K.  And as noted in the doc, it's NOT the exact size... just
close.

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

Nope.  If the result is coming from a pipe, no way.  If the stuff is
just in a text file say on unix, then you have to walk the file, count
LFs and add one byte for each of them: remember the standard is CRLF.
Etc for other platforms.

> 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.

The server will not keep the connection open.
And the reason for DATA <CR>.<CR> is the utter ease of implementation for
95% of all returns (which are text only).

>    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 Daniel stated, process table space is very expensive; making a connection
(even over 2400bps slip links) is very cheap.  This has been one of the
Gopher watchwords from day one.  If you don't believe the payoff, consider
the experience of sumex-aim (info-mac archives).  A year ago it was 
an ftp site that experienced melt-down loads under a stay-connected protocol:
FTP.  Now (while they still allow some amount of ftp) they are using gopher
as the recommended method of file transfer.  The time the user takes
browsing listings is many orders of magnitude higher than the actual time
taken for a transfer.

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

Users find this quite acceptable.  The time is very small in relation
to actual transmission anyway.

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

We don't find this to be true.

>    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.

As above.

>    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.

Think MACRO efficiency.  Forks are a dime a thousand on any good unix box.

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

Goodness!  NOT.

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

Now you have two :-)

BTW.  The size of the gopher-news list has climbed up past 400, and many
of the folks there will burn out if the techie/general-announcement ratio
gets too high.  Perhaps we should restrict the more techie stuff to
the usenet newsgroup comp.infosystems.gopher.

F.

--
Farhad Xerxes Anklesaria
Gopher Maven-In-Residence
Microcomputer Research Group
University of Minnesota
fxa@boombox.micro.umn.edu

Newsgroups: comp.infosystems.gopher