[14964] in Athena Bugs

home help back first fref pref prev next nref lref last post

Misc. netscape stuff

daemon@ATHENA.MIT.EDU (John Hawkinson)
Mon Feb 17 15:34:57 1997

Date: Mon, 17 Feb 1997 15:34:16 -0500 (EST)
To: "Bruce R. Lewis" <brlewis@MIT.EDU>
Cc: cwis-dev@MIT.EDU, bugs@MIT.EDU
In-Reply-To: "[14909] in Athena Bugs"
From: John Hawkinson <jhawk@MIT.EDU>

(formerly Subject: Re: netscape on athena only supports 40-bit encryption)

| >Bug reports for the infoagents locker should go to cwis-dev.
| 
| They should go to <bugs@mit.edu>.  This fact, as well as the use of
| usnetscape, is documented at

So noted. The netscape manpage installed in the infoagents locker
(manpage version is ostensibly 1.1N from 15 Aug 1995) reads:

{} BUGS
{} 	  If  you find a problem in the Netscape installation in the
{} 	  infoagents locker, you should send mail to the list  cwis-
{} 	  dev@mit.edu.  Keep in mind that Netscape is not fully sup-
{} 	  ported on Athena, so we may not be able  to  fix  problems
{} 	  due to bugs in the Netscape binary.

Incidently, I noticed recently that the annoying "I've created the
cache directory for you" message comes up with a window titlebar of
"Netscape: Error". Since my window manager doesn't normally display
title bars, I hadn't noticed this (but mwm/4Dwm does do this in the default
athena config).

I think the right thing to happen is therefore for the netscape
startup script to create /var/tmp/.netscape-cache-$USER.

While doing that, perhaps a lockfile-handling check could be implemented
so that users with stale .netcape/lock files could be given the option
to remove them prior to starting Netscape, and perhaps using a version
of the query that was less likely to confuse novice users.

Lastly, a question/plea. Netscape ships with the defualt # of
simultaneous connections set to four. This has always been somewhat
questionable to my mind

Anyhow, at this month's North American Network Operator's Group (NANOG)
meeting, Curtis Villamizer presented some of his simulation work
on when it's appropriate to use how many simultaneous TCP connections.
His presentation is available at
ftp://engr.ans.net/pub/slides/nanog/tcp-http.ps
.

Anyhow, he presents this largely in the context of 28.8kbps modem
connections, and most of his discussions about window size
consequently don't follow for our environment (it does mean
that perhaps we should reexamine our decision (based on my recommendation)
to up the TCP window size to 64kpbs, but I'd only suggest doing that
in the light of simulation and real data).

Anyhow, I'd like to suggest reducing the default number of simultaneous
connections to two, instead of four.

I've done this myself over the past few weeks and haven't seen a
noticeable performance degredation (and doing so is much better for
then network, as well as the servers on the other end).

What do people think?

--jhawk

home help back first fref pref prev next nref lref last post