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: [email protected] - CIS: 70751,252--