#Network Workings
39 messages in this thread
Off on a new thread… I'd like to talk about networks. I suspect there
has been some relevant discussions along these lines on Usenet, based on a
conversation I overheard at the NYC AmiEXPO. What would are good ways to
access machines and devices across the network? At the highest level, it
would be nice to decide which volumes could be shared between machines, at
the Workbench level. Clicking on that disk icon would bring up icons from
the other machine's volume, as if the disk were local. At another level,
what would be good ways to name the physical devices on another machine?
For example, how should you address DF0: on the machine across the room?
What about moving up and down directories on other machines, from file
requesters? What if someone removed that disk, which machine gets the
requester to "Please insert disk XXX"? What about strictly logical
assignments? Could you have "PPage:" located on another machine? What
about SER: and PAR: and PRT: on other machines? The general question is
"How would you like this to work?" more than "How could we program
this?"…
Yeah, it was this double-colon approach I was wondering about. I heard some
people complaining that it would make a lot of file requester
filename-parsing routines croak. It would be nice to avoid making programs
blow up. "Popeye:df0" (without the second colon) precludes the name "df0"
for directories, too.
In the conversation I overhead at AmiEXPO, John Toebes didn't like the
syntax of "Gumby:DF0:", because he thought the two colons would break a lot
of file requesters, and make it hard to parse and verify machine and volume
names. Something inside me made me wonder if he was against it because it
would break something in Lattice's file parsing routines, which I haven't
studied in detail.
Sounds like you were talking to some dyed-in-the-wool DEC types! If
there's anything "fixed with a nail" in the DEC world, it's the idea that
colons are RESERVED for device names. Using a colon to delimit a host name
as well must seem like rank heresy to such people. Since I can see (just
off the top) two or three rather simple ways to handl the syntax, I can't
imagine why a programmer of the caliber of John Toebes would have trouble!
Besides, if we use the Sun nfs conventions, the double colon never occurs
anyway, so it's a null argument.
The trouble is not writing new stuff, it's wih all the existing software
which would ont work correctly.
I look at it not so much as a colon delimiting a host name as a name used
to address the "network device" connecting two machines. 🙂 Why not
treat the device name on the remote system as a directory name, and make it
like this:
NodeName:df0/games/whizbang
Which would be translated by the remote machine as:
df0:games/whizbang
There are a number of project that I'm aware of that treat remote
directories in similar ways. Just curious about people's opinions on
this….does this sound resonable? I hope John Toebes hurries up and
decides how to do this….I hear he's working on this for a DNET device,
something I would LOVE to have!
Of course, anything that can get general agreement is OK. The syntax you
suggest can be made to work without trouble; all that is needed is to have
the appropriate translation done in one of the layers of the network
protocol. I really do believe that Sun's network file system paradigm is
the easiest for the user, though. In the nfs, there is no need for any
syntax for remote directories; all taken care of with the mount at boot
time (sound familiar?). When the nfs mount is finished, remote directories
(in Unix, file systems) look local. No syntax for remote stuff is
required. I've been using the nfs for the last 4 years or so, and have
come to like it very much.
The idea behind NFS is exactly what would work best, but unfortunately,
there is no static tree structure for all the volumes on the Amiga. That's
why I proposed what I did.
I wonder how AmeriStar's NFS handles this whole problem? Maybe if I'm
really lucky, I'll get an ethernet card to go with the Amiga I just got at
work, and I'll be able to find out first hand!
Of course, you're right about the tree structure, but I'm not sure that
hurts. Seems to me that the only practical way to handle it is just to
extend what good ole AmiDos does now. If you ask for a floppy that isn't
there, it puts up a requester. An attempt at a remote access for a floppy
that's missing should probably have the same results – at the remote
system. If that isn't acceptable, it should be reasonably simple just to
tell the local guy that the file isn't available.
For heavens' sake (and for all the rest of us), we have to keep the syntax
simple! I only have to recall VMS (and RSX-11) to see the syntactic
results of questionable design decisions early on. (Bet I get lots of
response over that one!
Steve, (Jumping in), I have an A2000 with the AmeriStar card installed at
work. I have an NFS mount to a Sun 3/260. It works very well, except that
the protect bits on the Sun seem to work a little different then on the
Amiga. If I do a MakeDir from the Amiga, I have to do a Chmod 777 on the
Sun to get the files readable from the Amiga. otherwise it works just like
the HD on the A2000. I can do anything with the files on the Sun that I
can do with files on the Amiga. Also the Amiga files on the Sun are treated
just like Sun files by the Sun. Its very nice to have 250 Mbs of disk for
those large animation files. 😎
What is the syntax for how you access files on the Sun? I'd like to see
a specific example, because I'd like to know how AmeriStar decided to do it.
Steve, The Sun is setup with the mountd and nfsd deamons, and the Amigas
hostname is put into the /etc/exports file. Then a mount command is issued
on the Amiga, which includes a 'local' device name ( nt0: is their
example). Then a disk icon appears on the Amiga workbench screen. From that
point on, you can do anything with it that you can do with a local disk,
except formatting and other such things. I can single click on the icon and
select 'info' from the workbench menu to see how many blocks are used/free,
open a disk window and copy files to it by dragging their icons into it,
or, use CLI commands to copy, read, run, and delete. I use one of the
campus computers to collect UseNet messages, FTP them to the Sun, and then
use KEEP12 on the Amiga to read them. I have also used TarSplit running on
the Amiga, to split a TAR file located on the Sun disk. ( I didn't feel
like reading the Sun manual to figure out how to run TAR on the Sun.) So
you can see that the NFS makes file handling very transparent to the Amiga
user.
Whilst you are:: quite correct about colon:: being used singly as device
delimiters, as in DF0:, DUA0:, etc., that is not their only:: use. A
remote node, GUMBY:: for example, would always be delimited by :: rather
than :. Thus the remote path syntax to my 'C' source directory at work
would be: GUMBY::DISK$SYSUPP:[NINGERSOLL.SOURCE.C].
I think you're looking a little too hard for "ulterior motives" here. I
think that it is a valid statement that the occurrance of a double-colon in
a path name would break a lot of path parsing routines. It has nothing to
do with it happening to break Lattice's library or not (I don't have the
answer to this one), but that it departs from the current way of doing
things in enough of a way as to confuse a number of programs. That's why,
in my proposed approach, the volume name on the remote system was treated
more as a directory, and the network name was treated as a volume. Single
colon syntax, which would work with all current path parsers. The volume
(device) would then be able to be handled by a different device driver.
Ulterior motives? 🙂 You mean, it breaks Saf-t-net?
I really don't know off-hand if it breaks anything in saf-T-net or not.
It wouldn't surprise me, but it doesn't concern me either. Such a file
name is not currently supported (or legal) on the Amiga. Were such a file
naming standard to become an accepted part of the Amiga environment, either
through the blessings of Commodore, then it would become supported by my
commercial software packages, including saf-T-net. If on the other hand,
this "standard" was implemented and accepted solely by a third-party
provider, then my decisions concerning support would depend on the success
of that third-party product and on the demands of my customers. Cooperation
on the part of that third-party provider would definitely affect my
decisions.
As far as my "ulterior motives" in the previous message — I did not
consciously have any — hadn't even thought of it in the context of it
breaking either saf-T-net, Empire, or my current project. If you want to
doubt me, so be it.
There *was* a smiley in that message. Is "ulterior" the word of the week?
Why doesn't anyone like the UNIX method of using the '!' to
designate the 'node' or machine name of origin? If my Amiga has the node
name 'dc' and someone else on a network with my machine wants to mount my
HD, they could easily mount DC!DH0: and use Assign to give it a shorter
name.
I wouldn't mind that method, Don. '!' is a legal AmigaDOS filename
character. So you could have a logical assignment for "DC!DH0:" right now –
I guess that means things wouldn't break.
Hmmm… well, an exclaimation point as host seperator would work just
fine… and nothing would break. Well, except for Access!, Whap!,
OnLine!, Calc!,… <wide silly grin>
Well, gee, then maybe….just maybe….we could use —> \ <— instead!
(running desperately to get clear of the flames)
Why would they break…they don't end with a : and you don't mount them.
There WAS a grin in that message… I was being facetious. What with the
panic stricken by the suggestion of a colon as a node indicator because
things would break, then you suggesting the exclamation point instead…
well, all those wonderful programs which end with "!" lept immediately to
mind.
In all seriousness, you WOULD have to be careful how you parsed things,
since a single command on a line ("Whap!") could be confused for a node
name ("Plato!DH3:Access!") if you took too many things for granted.
Also in all seriousness, the _safest_ thing to do would be to reserve a
character for the node indicator which is illegal in file- or pathnames.
But wouldn';t the break most file requesters? Also just for my info, what
characters are illegal in AmigaDos File Names?
No, seriously…using a ! would be in the mount command only, after
that, it'd be addressed as a 'normal' file:
HisDrive: Device = remote.device
Filename = mach1!mach2!dh0:
#
Mount HisDrive:
Run HisDrive:Whap!
If It was allowed, and I wanted to fully address the file, the
delimiter between "where" and "what" is the colon so there should be no
confusion for a parser.
That would sure work except that the mountlist could get rather unwhieldy
for large networks.
I guess it would work, but I think every time I would see that I'd think of
UUCP. 🙂 Hey! This is along similar lines to what you thought of….you
could address it as:
df0:directory/subdirectory/file@NodeName
Hmmmm…..I'm not sure I like this as much as suggestions I've made in
other messages.
That's exactly why I like the ! character for node-name delimiter.
It's already in use, it works and allows multiple remote nodes. Let's say
I want to read a file that is 3 nodes away, and I don't have direct connect
to that machine (for whatever reason), then mach1!mach2!mach3!df0:filename
would work just as it does now. If I had a direct connect to that 3rd
machine, then a simple mach3!df0:filename would suffice.
Steve's other suggestion is also in use. I personally like the '!' idea
best and think that it is a bit easier to understand. The @nodename method
is part of the level 4 (5?) protocol. It is intended for use with
automagic routing.
That works fine (the mach1!mach2!mach3!df0:filename) except where
'filename' happens to be Whap! or Access! – then it gets a little
confusing. I realize that the parsing from the left of the address can stop
when it reaches the ':', but I still find it confusing — kind of like
allowing the ":" character to be part of the machine-node name. 🙂
The parsing could come from either the right or the left, it shouldn't
matter.
Parse from right to the first colon for local path/filename
:terminals/programs/george/harry/Access!
Parse from the left to the first colon for node path
mach1!mach2!mach3!whereever:
The colon retains it's current meaning, so exclamation marks in the
filename would have no more significance than they do now.
I think it ultimately depends on the type of network we're talking about.
If it's a rather unintelligent network (such as USENET), then the
mach!mach!mach3!df0:file would work well. A more sophisticiated network
setup with a database could use machine:df0/file…..or whatever.
Another method that I've been working with for about 3 years now has an
optional network specifier at the start of the path name, as in:
[optional_node_identifier]df0:directory
Something similar to this could be easily implemented. If the [id] is
missing, the assumption is the local node.