asher@uhura.cc.rochester.edu (Samuel Asher) (12/01/88)
I am trying to allow people on our Appletalk to print on laserwriters in another university. Both of us have Fastpaths and run atalkad on Unix machines to load zone info. It seems that all I need to do is to put entries for the foreign fastpath into my local atalkatab file to allow local Macs to see the foreign zone. Two questions: 1) Am I overlooking something? 2) Must all the zone numbers on both sides be unique? In other words, if we have zone numbers a, b, c, and d; they have zone numbers a, b, c, and e; can we access/reference their zone e without changing any of our net numbers? -Sam Asher University of Rochester asher@cc.rochester.edu
minshall@kinetics.UUCP (Greg Minshall) (12/06/88)
From article <8811301634.20655@uhura.cc.rochester.edu>, by asher@uhura.cc.rochester.edu (Samuel Asher): > > I am trying to allow people on our Appletalk to print on laserwriters > in another university. Both of us have Fastpaths and run atalkad on > Unix machines to load zone info. Yes, this should work. > It seems that all I need to do is to put entries for the foreign fastpath > into my local atalkatab file to allow local Macs to see the foreign zone. I *believe* you will both need to put at least one entry into your atalkatab for one of the "foreign" KFPS's (and label it with the "C" flag to make it a "core" gateway; this same gateway should be labelled "C" in the foreign atalkatab file), and the "foreign" site should do the same for one of your KFPS's. > 2) Must all the zone numbers on both sides be unique? In other words, > if we have zone numbers a, b, c, and d; they have zone numbers a, b, > c, and e; can we access/reference their zone e without changing any > of our net numbers? There aren't "zone numbers". There are "zone names" (which define a "zone") and "network numbers" (which define a "network"). A "zone" is a bucket, and each "network" is in exactly one bucket (zone). Zone names do not have to be unique between the "local" and "foreign" installation (but probably should be so that people can distinguish between the laser writer in one math department and in the other). Network numbers, on the other hand MUST BE UNIQUE. Greg Minshall Kinetics, Inc. ucbvax!unisoft!kinetics!minshall (415) 947-0998 ps - As the "*believe*" above indicates, I've never tried this. I would be very interested in your results (as I imagine other people on this list would be).
minshall@kinetics.UUCP (Greg Minshall) (12/07/88)
From article <674@kinetics.UUCP>, by minshall@kinetics.UUCP (Greg Minshall): > From article <8811301634.20655@uhura.cc.rochester.edu>, by asher@uhura.cc.rochester.edu (Samuel Asher): ... >> I am trying to allow people on our Appletalk to print on laserwriters >> in another university. Both of us have Fastpaths and run atalkad on >> Unix machines to load zone info. ... >> It seems that all I need to do is to put entries for the foreign fastpath >> into my local atalkatab file to allow local Macs to see the foreign zone. > > I *believe* you will both need to put at least one entry into your atalkatab > for one of the "foreign" KFPS's (and label it with the "C" flag to make > it a "core" gateway; this same gateway should be labelled "C" in the > foreign atalkatab file), and the "foreign" site should do the same for one > of your KFPS's. Sigh. I realized on my way home last night that my response was untrue. In fact, the only services you can communicate with are those which are connected to K-boxes listed in YOUR atalkatab (and for those services to be able to send to you YOUR K-box needs to be in THEIR atalkatab). So, lots of entries need to be duplicated between the two atalkatab files. Additionally, Charlie Kim mentioned that if IP fragmentation occurs in the path between one K-box and the second K-box, then communication breaks down. This is true for both KIP and K-STAR (for while K-STAR *does* do IP fragmentation, it does NOT do IP reassembly). Finally, Charlie mentioned (in a message which may or may not have gone to this list) that, in particular, laserwriters may not perform too well since they will get timeouts over "long" routes. Greg Minshall Kinetics ...!ucbvax!unisoft!kinetics!minshall (415) 947-0998