vthrc@uqvax.cc.uq.oz.au (Danny Thomas) (01/14/91)
References: <849@organpipe.UUCP> Organization: VTHRC, University of Queensland In article <849@organpipe.UUCP> royce@scoraz.resp-sci.arizona.edu (Royce Robbins) writes: > Advantages include: > Low cost - can recycle existing hardware, any new hardware is quite > inexpensive and can be purchased in small increments. > Higher speed - using a FlashCard in the PCrouter and FlashBoxes on > LocalTalk devices will give better than three times the performance of > AppleTalk. FastPaths etc., won't work at FlashTalk speed. > Less server overhead - The whole CAP/UAB/KIP suite is unnecessary. > AppleShare without a dedicated AppleShare server. > Disadvantages are: > No non-local AppleTalk routing. > Only one LocalTalk interface per PCrouter. ^^^ > Changing number or type of interface requires recompiling PCroute with Turbo Assembler. One thing left out of RoyceUs list is PCRouterUs ability to support multiple interfaces. At present ours has a backbone ethernet and two LocalTalk interfaces (half a MultiGate, but for TCP/IP only), and will probably be expanded with two more ethernet cards. The PCRouter would then be handling two separate nets, each with an ethernet and AppleTalk segment. Does anyone know whether the code from PCBridge has been integrated into PCRoute yet, cause IP bridging between ethernet and LocalTalk for each of the nets would be more than useful in the expanded configuration. N.B. the reason for running two nets into the router is that shortly(?) it'll be connected onto the campus backbone via the glass-fibre link into this building, but if there is more than one interface onto the backbone things become rather more expensive. It'll be doing the job of both a router (e.g. a WellFleet) and an ethernet/LocalTalk interface (e.g. FastPath), allup cost around $2000 (in Oz a FastPath cost around $4000)! Of course it only handles IP and I wouldn't recommend it for high traffic situations, but it is adequate for many departmental situations. It is easy to configure the PCRoute software for two LocalTalk boards; the problem comes about when you try and load a separate FlashCard (software) driver for each card. The second ATALK.EXE detects that one is already resident and refuses to load. Sometimes life is easy and simple hacks work; in this case modifying the driver name embedded at the beginning of one of the ATALK.EXE binaries from "ATALK.SYS" to something else does the job! I used "BTALK.SYS", but you could probably use anything else. The only thing stopping you from using more cards is the inability to choose from more than 2 I/O addresses. Some people might also find the small selection of interrupt levels annoying. We are also thinking of modifying a board to accept a DIN-8 socket so we can use the same PhoneNet connectors for both Macs and PCs (you can buy them cheaply in packets of ten). A simple PC hardware question is whether more than one board can run under DMA. Now for some questions: has anyone modified PCRoute to accept the LocalTalk card made by Apple. I borrowed one and it didn't work, nor would TOPS software recognize it. I assume it has a completely different programmatic interface. Presumably quite a bit of the AppleTalk protocol is handled by the 65xx processor on the card, furthermore the latest version of the software handles a network running AppleTalk phase 2, which might be handy for some folks. I donUt know whether the latest TOPS software driver does that, nor have I tried hard to get it to work, but would like to hear from anyone who has. I donUt know much about DaynaUs LocalTalk board either. I have briefly thought about bridging AppleTalk between ethernet and LocalTalk interfaces. Bridging makes it looks like ethernetted and LocalTalkUd machines are on the same net (zone) and shouldnUt be too difficult cause you donUt have to support any of the higher-level AppleTalk protocols that deal with routing, zones, etc.,*that* sort of thing would be non-trivial, an exercise for the reader as they say. In bridging you donUt have to deal with the contents of packets (i.e. protocols) but merely source and destination addresses. You dynamically construct (and continuously maintain, since AppleTalk uses dynamically assigned addresses; ARP is the only protocol the bridging code has to deal with) a table saying which node addresses belong to which interface. You have to look at every packet and if the destination exists on the other interface, queue it for transmission out of that one. Broadcasts are always passed. Things get harder if you want to use the same interfaces for IP routing as well. When bridging you must use the LAP level to grab every packet from the net and inspect the addresses, but IP stuff is dealt with in higher levels of the protocol stack above those dealing with sockets. Does anyone have any thoughts, corrections, suggestions, experience along these lines. This could be useful to people considering CAP now that it supports EtherTalk. Danny Thomas, Vision, Touch and Hearing Research Centre University of Queensland.
maas@JESSICA.STANFORD.EDU (01/15/91)
>Now for some questions: > has anyone modified PCRoute to accept the LocalTalk card made by Apple. I >borrowed one and it didn't work, nor would TOPS software recognize it. I >assume it has a completely different programmatic interface. Presumably >quite a bit of the AppleTalk protocol is handled by the 65xx processor on >the card, furthermore the latest version of the software handles a network >running AppleTalk phase 2, which might be handy for some folks. I donUt >know whether the latest TOPS software driver does that, nor have I tried >hard to get it to work, but would like to hear from anyone who has. I >donUt know much about DaynaUs LocalTalk board either. The programming interface of TOPS and Apple drivers are the same (the same is true for Dayna). For AppleTalk driver that comes with AppleShare PC2.0, you have to run COMPAT.COM for compatibility with the AppleTalk driver version 1.0 that uses interupt 60 for driver calls. Andy Maas Networking & Communication Systems Stanford University