Re: NetScape...)

Ramin Firoozye (rpa@netcom.com)
Wed, 2 Nov 1994 09:34:05 +0100

carl@cavebear.com writes:
>
> I'm not disagreeing with your comments... my own feeling, however, is
> that in terms of the overhead imposed on servers, the number of
> simultaneous requests is a smaller issue than the effective use (and
> re-use) of transport connections.
>
> Commenting in response to the folks who say that a server reaches
> steady state whether the clients are single-connection or
> parallal-connection: I agree with the note that with faster user
> response, the user may read more pages over a given period of time.
> This will increase the steady state load by some amount. (My feeling
> is that it would be less than 25% for a population of serious
> browsers, and a higher percentage for a population of wild surfers)
>

I think the reason so much heat is being generated over this (apparently
minor) nit, is that Mosaic pushed a lot of people into getting TCP/IP
onto their desktops (for the Mac/PC crowd). Most of the implementations
have static tables that limit the number of sockets available for general
use. The same is true of a number of older Unix implementations. I seem
to recall 64 as being a general number. Some limited this to 32 mainly
due to a faulty implementation of "select" and the FD_xxx bit-setting
macros limited to longword sizes.

The heat seems to come from people who would like to see their own
apps run on all these desktops, but are concerned that either their app
will run out of sockets to use when a user unknowingly sets the connection
count to a ridiculously large number, and then tries to multitask their
app as well, or from those who now are faced with having to open a similar
number of connections if only to appear as "fast" as NetScape when
transferring information.

In either case, it all boils down to whether you want to cooperate
with the rest, or reach for as many free resources as you can get your
mitts on. The NetScape approach does up the ante: now everyone is going
to have a "number of connections" in their clients (or worse, they won't
even ask, just grab 'em all).

I worked on a server with a client library 3-4 years ago that opened multiple
sockets on demand. It was decided after the first pass that this was
not a good neighbor thing to do and it was taken out. We figured it would
piss off a lot of people. Kinda glad now (;-)

I wish instead of going this route, the MCC guys had sat down and come with
a nice UDP-based lightweight binary protocol with built-in compression
and caching that would seriously kick butt...

Just day-dreaming here...

Sigh...
R.

-- 
Ramin Firoozye' 
rp&A Inc. - San Francisco, California
Internet: rpa@netcom.COM - CIS: 70751,252

--