4.4BSD/usr/src/old/berknet/BUGLIST

Network Status 		November 5, 1980

BUGS
----
--	Various response messages are lost.  This includes "fetching"
	files when the file being retrieved never arrives.  I suspect
	this has something to do with unreliable delivery of error messages,
	but this is not reliably reproducible.

--	The net command will create files in the queue directories
	without the corresponding control files ("dfa..." without "cfa...").
	Unknown cause.  They should be periodically removed.
	(Perhaps caused by an error such as an invalid machine name.)

--	The network makes no provision for errors in transit on intermediate
	machines, such as "No more processes" or "File System Overflow".
	While these occur only rarely, when they do, no message or
	notification is sent to anyone.

--	The network daemons occasionally core dump.  They should not.
	

SUGGESTIONS
-----------

--	Maintenance Improvements:
	The network has become large enough to make re-compilation
	of the source on all machines to become practically impossible.
	The net command has compiled within it a routing table for each
	remote machine (defined in config.h).
	Adding a new machine to the network requires recompiling the
	net command on ALL machines.  The net command should read an
	external text file to compute its data structures.
	There is a program patchd, written by Bill Joy, which could
	be used to patch the binary versions of the network
	on like-systems, such as the Computer Center machines.
	The network code should use the retrofit library for
	non-Version 7 systems.

--	The possibility of a number of small UNIX personal machines wanting
	intermittent access to the network looms ahead.  We should attempt
	to organize the software to allow occasional use
	by other UNIX machines, without tying down a port all the time.

--	Bob Fabry has suggested the "machine" be generalized to imply a 
	machine/account pair, e.g. -m caf would imply "caf" on Cory,
	-m Cory would imply "fabry" on Cory.
	Environments could provide this information.   
	It has also been suggested that the notion of a "default" machine
	is too restrictive and that each type of command should have a
	default machine, e.g. netlpr to A, net to B, netmail to C, etc.

--	Colin has developed some data compression algorithms.  On machines
	which are normally CPU idle, his algorithms could be used to
	compress data and speed up file transfer.
	Each individual host could decide whether data should be compressed,
	and each receiving machine would be able to handle both compressed
	and uncompressed data.

--	Files being retrieved, or fetched, are created zero-length
	as the request is sent to the remote machine.  An alternative 
	would be to put the message "File being transferred." in the file to
	make things clearer.

--	File modes should be preserved across the network.  Currently
	they are set to 0600 most of the time.

-- 	It would be nice if the rcs facilities and commands on various
	UNIX machines with rcs links were more accessible from machines
	without an rcs link.

--	The network was not expected to become as large as it has.
	Not much thought was given to large networks.
	The netq command only lists queues on the local machine,
	but many times the user is waiting for long queues on intermediate
	machines.
	Likewise, once the request is forwarded to the nearest machine,
	the netrm command will not let the originator remove the queue file.
	Finally, a network status command telling people what the network
	was doing would be very helpful.

--	The underlying protocol is wasteful and/or confusing:
	* Compute a full checksum on the entire file in addition
	  to the checksum per packet now provided.
	It is unlikely these will be changed since all the daemons
	on the network machines would have to be changed at once.

--	The netcp command should allow the user to default one of
	the filenames to a directory, ala the cp command.

--	File transfers, like remote mail, should be possible from
	the Berkeley Network to the Arpanet and the Bell Research Net.
	This is not difficult technically, but requires UNIX-like
	stream interfaces to be written for the gateways.

--	Currently the network files being transferred are
	copied into /usr/spool... it would be nice for
	large files to simply use a pointer to them.
	(To save time and space).

--	The scheduler the daemon uses is very simple.
	It should have a way to age priorities and to "nice"
	transfers, to be done after all normal ones are done.
	Also, there are some network uses that are time-dependent.
	It would be nice if certain queue files would disappear
	at certain times, if for example, a remote machine were down,
	given that they are no longer useful.