🚀 go-pugleaf

Interesting--
	John Castler from Syracuse University and I have requests from
our respective superiors to do what it takes to tie U of Rochester
and SU appletalks together-- at least have remote printing, if not
total zone transparency.
	Things have been somewhat on hold for me because of other
responsibilities, but here is what I have so far:

	Problems to overcome:
	1)  There must be a Number Czar.  We cannot each run our own
	atalkad programs with arbitrary (usually identical) network
	numbering schemes in the atalkatab.  This is exactly the problem
	with massive DECnets...

	HEPnet overcomes this problem by pre-assigning some range of
	numbers, then leaving another range for Local-Use only.... 
	ie: the second range is some "private" range that each member
	institution uses as it pleases.

	All this overlapping number stuff really smells bad to me.
	Anyway, NYSERnet Inc. has offered to be the number czar for a
	New York State appleNet over NYSERnet bandwidth.

	2)  KIP and K-Star do not collate fragmented IP packets.
	So, if there is some zone information or other network packet
	(like from a document going to a remote laser printer) that gets
	broken up by an intermediate device, the receiving Kinetics
	box will not be able to reassemble the packet from the pieces.

	Now, there have been two messages on info-appletalk (one from
	Patrick Gaughan (pgaughan@nmsu.edu) and one from Phil Farrell
	(farrell@erebus.stanford.edu) that say (I paraphrase):

		If all you want to do is laser print, just use the
		laserwriter spooling program from the Columbia
		Appletalk package-- lwsrv.  Basically, define a
		spooler on your local Unix machine that is visible to
		the local appletalk.  However, instead of printing
		on a local printer, it sends the print job to a remote
		spooler program on a remote Unix machine.  The remote
		program prints the file onto the remote Apple LaserWriter.

		This way, any IP packet reassembly is done by
		the intermediate Unix machines.  Additionally, you don't
		have to wait on the initiating Mac for the potentially
		large job to be completed, and, you don't have to worry
		about laserwriter timeouts.

	This is pretty cool stuff, and it may be the greatest amount
	of functionality we can hope to achieve until there is some
	cure for the fragmentation problem.  I am told that proteon
	is working on an Appletalk interface board that would fit into
	one of its routers.  I am told that Cayman is working on correcting
	the same problem on their GatorBox.  However, I have not gotten to the
	point of even seeing the problem, nevermind worrying about the
	fix.

	3)  Protection is unkown-- While we live in an open world where
	everyone loves each other and does not unto others as they would
	not want done unto themselves, there are martians and other evil
	extraterrestrials that would see the Chancellor's printer on a
	zone and print pornography on it.  Of course, this possibility
	exists within our campus now, but we're talking accountability.

	Basically, I am concerned that Kinetics does not support even the
	meager zone protection scheme of KIP with their K-Star program.
	(If you are doing something about this, Kinetics, Please respond!)

	4)  Performance/timing problems-- I am not quite sure about this,
	but I am told that timeouts built-in to current appletalk programs
	reflect a fairly simple model.  This seems to be adequate for
	our campus wide appletalk internet, however, even here, some
	slow unix machines and routers cause less than perfect behavior.
	I expect this to be magnified if/when we introduce the added
	variance in delays caused by traversing a whole bunch of other
	systems (internet router, shared T1 link, remote router, remote
	ethernet, etc.).


	I hope this helps.  Please keep your work posted, as there is
	much interest in such stuff.

		-Samuel Asher
		-University of Rochester