luke@tasis.utas.oz (Luke Visser) (06/14/88)
Ok, the question is this, how do I find what zones are accessible from a
particular Mac attached to a network?
From what I can tell there is no specific AppleTalk calls that will do job,
and in fact that sort of information is not resident in the Mac (in a place
that I can get at). However, the Chooser does it!
We use MultiGate (an AT bridge) and from the details that accompanies it
it has the zone names that are (physically) connected to it hard-programmed
into it. Does that mean that I have to get that info from it or
does my Mac load it at startup time (I doubt that).
Since the zone names are hard-programmed into MultiGate (I suspect other
bridges are the same), how does it find out about zones that it is
not physically connected to (i.e. connected to another bridge via EtherNet)?
Is there a method of calling the bridge so that it returns the zone names
that are hard-programmed into it and then also having that request cascaded
to all the bridges that it is connected to?
Can someone in Apple explain the rationale of zones, from what I can tell
from the doco and also talking with some of the net people here they are
somewhat of a pain.
Luke Visser
---------------------------------------------------------------------------
Snail: Uni of Tasmania, Box 252C GPO, Hobart 7001, Tasmania, Australia.
ACSnet: luke@tasis.utas.oz ARPA: luke%tasis.utas.oz@uunet.uu.net
UUCP: {enea,hplabs,mcvax,uunet,ukc}!munnari!tasis.utas.oz!lukepalevich@Apple.COM (Jack Palevich) (06/18/88)
In article <620@tasis.utas.oz> luke@tasis.utas.oz (Luke Visser) writes: >Ok, the question is this, how do I find what zones are accessible from a >particular Mac attached to a network? It's not too hard. You have to ask the bridge for the names of the zones. You do this by: 1) Using GetBridgeAddress to get the bridge address. If there isn't a bridge, there aren't any zones, so your zone name is "*". 2) Send an ATP request to socket 6 of the bridge. The userData field is either $07000000 (if you want the name of the local zone) or $08000000 + index, if you want the names of all the zones that the bridge knows about, starting with the "indexth" one. The index starts at 1, not zero.... 3) The bridge will send you back a 1-packet response which contains either the name of the local zone (if you used $07000000) or as many of the zone names as will fit into a packet. The names are stored as Pascal strings. The userBytes field of the packet you get back will have the number of zones returned in its least signifigant two bytes. The most signifigant byte will be set to zero if there are more names to get. 4) If there are more names to get, add the number of names you just got to the index, and go back to step 2. 5) Once you have all the names, you should sort them into alphabetical order before displaying them to the user. Here at Apple we have over 50 zones, and it's a real problem trying to find a particular zone in an unsorted list. ---- Of course, a much more complete description of all this can be found in the manual "Inside Appletalk". I think that this manual is available from APDA. ---- In response to your question "Why Zones?", the answer is that, once you have a large network, you run into exactly the same computational and user-interface problems that are posed by directories on a large disk. Zones act like folders -- they partition the network into more managable chunks. --------------------------- Jack Palevich, Advanced Technology Group, Apple Computer, Inc. Disclaimer: Although, to the best of my knowlege, this information is correct, this message is not an official pronouncement by Apple Computer, Inc. Use the information provided at your own risk.
cck@cunixc.columbia.edu (Charlie C. Kim) (06/18/88)
In article <620@tasis.utas.oz> luke@tasis.utas.oz (Luke Visser) writes: >Ok, the question is this, how do I find what zones are accessible from a >particular Mac attached to a network? > I'm not sure if there is a Mac library call (it would be in IM V if it were), but is not difficult. You send an ALO (e.g. not XO) ATP request to the local bridge at socket ZIP=6 and ONE response allowed with the atp user bytes set to: first byte: zip command 7 = Get My Zone, 8 = Get Zone List second byte: always zero third, fourth byte: index (zero for get my zone) Get My Zone returns the zone name of your connected network. Get Zone List returns the list of zone name starting at the index (first index is 1). The original specification (pre-EtherTalk) says that you should send this as a short ddp -- this should not be a problem on a mac -- you won't be able to stop it if you use atp to send the packet :-). The response packet atp user bytes are interpreted as: byte 1: last flag (not positive which bit it is) byte 2: byte 3,4: number of zone names returned The zone names are returned as a packed list of pascal strings. Since there may be more zone names than may be returned in a single response, you must reissue the request with a "updated" index (based on the count returned already) until lastflag is set in the response. >... >Since the zone names are hard-programmed into MultiGate (I suspect other >bridges are the same), how does it find out about zones that it is >not physically connected to (i.e. connected to another bridge via EtherNet)? > There is a "reactive" Zone Information Protocol (ZIP) that queries for zone names of networks when it receives information about other networks from RTMP (routing table management protocol). The zone list the above returns has a list of zone names of ALL networks reachable by your bridge (I wish we had multigates as the standard in the u.s.!) that have a zone name set (all should have a zone name) after a settling period that is determined by a number of factors (mainly when the various bridges were booted). It really sounds like you need a copy of "inside appletalk" (against which with the command descriptions given above should be checked). This document, available in the u.s. from a.p.d.a., contains information about the various appletalk protocols. In conjunction with the ethertalk specification whose definitions supercede those of inside appletalk--in particular, it says that long ddps are legal where short ddps are specified in ia when using ethertalk and in fact short ddp's are strongly discouraged on ethertalk--ia is the definitive (read: only) specification of the base AppleTalk protocols. (The appletalk filing protocol and appletalk data stream protocol (DRAFT status) definitions are not included in i.a. and the specifications are available seperately from a.p.d.a.). If you don't have access to a.p.d.a. in australia, contact your friendly apple representative. >... >Can someone in Apple explain the rationale of zones, from what I can tell >from the doco and also talking with some of the net people here they are >somewhat of a pain. > I'm not from apple, but in a nutshell, from a functional point of view, zones are useful to "group" different "networks" together so that when you look for a laserwriter you don't see 1000 of them showing up. By network, I mean a single appletalk/ethertalk cable that is assigned a unique "network" number. A "internetwork" consists of networks connected with appletalk bridges. Again from a functional viewpoint, another way of putting it, is to say that the zone names extends the name of the various "entities" on your networks allowing you to be more specific in your queries (e.g. instead of "show me all laserwriters in the internetwork" you can ask "show me all laserwriters in the networks that belong to a particular zone"). NBP (name binding protocol) is what actually uses zones. When you do a lookup for LaserWriters, then the lookup is BROADCAST on every network in the zone you are doing the lookup in - if all your networks in your internetwork are in a single zone (e.g. roughly equivalent to an environment without zones) then the lookup will go to all those networks. So besides the "user interface" reasons, there are serious performance reasons to use zones when you have a large number of networks (O(100)). It's not just the wasteful traffic on the networks though (which can degrade throughput): all broadcasts must be processed by every node! When you have a internetwork containing 1000s or even 100s of macs, the level of broadcast traffic can get annoyingly high (quite often people forget to drop out of chooser -- especially when doing appleshare because of the way the multiple dialog boxes come up). Not to mention the overhead on the responding machines. Don't be tempted to put every network in its own zone though because when you exeed about 20 (only about 8 are shown at a time), it becomes a real chore dealing with it in chooser--for me that is. then again I have a problem with cdevs in the control panel too: I can't either of them to scroll to the place I want without flying by 2-3 times. Often I've wished you could type the names in like you can in sfgetfile. What i really want is for the chooser to just go to the zone i want! Of course, the best I can really ask for is to for it to let me do pick out the "correct" zone with a minimum amount of pain though which is not the case now and we only have 13-14 zones defined). meta/hierarchical-zones (collections of zones) seem at first thought to help by reducing the number of choices at each "look", but they create another problem: you have to remember what metazone the zone you want is in (unless you can locally define what the metagroups are, then you have fighting chance -- oh if I could only specify the order the zone names came up in some the ones I used most often came up in the first 8-9 -- same thing for anything based on lists on the mac).... (Of course, depending upon how the zones are done -- if you assign them by physical location, it would be nice if you could click point parts of a map to select zones -- if you assign by workgroups, then it would be nice to have heirarchical groupings based on organizational structures -- if you assign at random, tnen forget it :-). Thus, zones might be a bit of pain, but you don't have to use them and they are nice in grouping entities (and in restricting a particular class of broadcast traffic -- already too much of it in appletalk). What is nice is that the way things were designed (without respect to magnitude problems) that what most people would consider the more "user friendly" or "nice" choices generally correspond to "reasonable" technical options with respect to network overhead. Charlie C. Kim User Services Columbia University
cck@cunixc.columbia.edu (Charlie C. Kim) (06/18/88)
I realized that in editing, my last posting ended up with the wrong words in one place (the run on sentences and the grammar and fuzziness in parts are another problem, but... ). >then you have fighting chance -- oh if I could only specify the order >the zone names came up in some the ones I used most often came up in ^^^^ so that Charlie C. Kim User Services Columbia University