[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Marinetti over LocalTalk/Appletalk?



In article <f6ab8a2f.0202172112.32057547@posting.google.com>,
 andrew.roughan@writeme.com (Roughana) wrote:

> Thanks very much for your analysis and input.
> I'm learning a lot about Appletalk.
> 

I hope it helps! :)

> jalapeno1@mac.com (jalapeno) wrote in message 
> news:<2f367031.0202150833.538c138b@posting.google.com>...
> > We can write our own IP Gateway if you have a LanceGS card.
> > IP Gateways are easy (famous last words ;) to program and the
> > MacIP docs tell you what you need to include.
> I believe that the LanceGS comes with it's own Link Layer for
> Marinetti.
> So this is probably not necessary.
> Would anyone with a LanceGS care to comment?
> 

The LanceGS does come with its own link layer and that would be needed 
for a MacIP gateway. One possible block diagram for a IIGS IP Gateway 
would be (off the top of my head):

+---------- begin ascii art -----------+

  +--------------------------------------+
  |               IIGS                   |
  |                                      |
  | +--------------+   +--------------+  |
  | |              |   |              |  |
  | | Marinetti    |   | Appletalk    |  |
  | | TCP/IP stack |   |   stack      |  |
  | |              |   |              |  |
  | +----o----o----+   +--o----o------+  |
  |      |     \         /     |         |
  |      |      \       /      |         |
  |      |    +--o-----o--+    |         |
  |      |    |   IIGS    |    |         |
  |      |    |    IP     |    |         |
  |      |    |  Gateway  |    |         |
  |      |    |           |    |         |
  |      |    +-----------+    |         |
  |      |                     |         |
  |      |                     |         |
  |   LanceGS               Localtalk    |
  |   ethernet               builtin     |
  |     card                  port       |
  |      |                     |         |
  +------O---------------------O---------+
         |                     |         
         Z                     Z          
         |                     |         
      ethernet             Localtalk      
       network               network     
         |                     |
         Z                     Z        
         |                     |         

+---------- end ascii art -----------+

Marinetti would be the gatekeeper for the ethernet network and the built 
in Appletalk stack would be the gate keeper for the Localtalk network.

The IIGS IP Gateway software would install socket listeners (a DDP 
[datagram delivery protocol] socket listener on the Appletalk stack and 
an IP socket listener on Marinetti) to watch for traffic on both 
networks. 

When a MacIP packet comes in on the Localtalk network then the IIGS IP 
Gateway program would strip off the DDP header and send the remaining IP 
datagram to the ethernet network via Marinetti. 

When an IP datagram comes in via the ethernet network the complete IP 
datagram that Marinetti stripped from the ethernet packet would be sent 
to the IIGS IP Gateway software which in turn adds a DDP header and 
sends it to the Localtalk network. 

If the destination on the Localtalk network is another IIGS then that 
IIGS would have its own Marinetti with the MacIP link layer running and 
(the local copy of) the Marinetti link layer would strip off the DDP 
header from the IIGS IP Gateway and Marinetti would process the IP 
datagram in the usual fashion.

I don't know how Marinetti functions but the DDP socket listener will be 
called via an Appletalk interrupt (this is handled by the firmware and 
the Appletalk driver). If Marinetti doesn't operate via interrupt then I 
suppose you'd need a tight loop to poll for IP datagrams.

So I guess (again, off the top of my head) one possible algorithm for 
the IIGS IP Gateway would be (omitting all error checking and 
implementation details):

1. At launch check for Appletalk and Marinetti being installed and 
active. (from here on assume they are)

2. Register on the Localtalk network as an IPGATEWAY (following the 
normal Appletalk NBP registration sequence with the addition of an ATP 
socket listener so new IP addresses can be assigned when new MacIP nodes 
come active).

3. Broadcast on the Localtalk network for any entities registered as 
Object type IPADDRESS. If any respond add their Appletalk node and IP 
address to the translation table. This might need to be done prior to 
step two but this is the order it came to me :)

4. Wait for appropriate network traffic.

5. Add DDP headers to ethernet traffic going to MacIP Localtalk nodes 
and send it to the Localtalk network. This includes extracting the IP 
address and converting it to ascii and adding it as the Object name 
(without the period separators) in the DDP header.

6. Strip DDP headers from Localtalk traffic coming from NVE's of Object 
type IPADDRESS and send it to Marinetti.

7. Rinse and repeat 4-6 :)


> > With a IIGS IP Gateway you can get rid of your
> > Powerbook and IPNetRouter all together :)
> The idea behind my investigation is to get a solution working that
> uses MacIP across Appletalk to something. This will allow the
> documentation of the solution for others who may have this gear
> available to them.
> 

Yes, I understood. But why stop there? Think BIG! :)


> > Ok, it sounds like IPNetRouter is using your Mac's OpenTransport or
> > MacTCP client to send via Localtalk.
> I am using OpenTransport with MacOS 8.1.
> 
> > Do you have a Localtalk packet sniffer? 
> No. I have searched for one in software for the Mac.
> LocalPeek does not seem to be available anywhere. Broken links
> everywhere.
> 
> > Actually, a IIGS packet sniffer shouldn't be hard to write (famous last 
> > words again) since LLAP is built into the firmware. 
> Would this need to sit on a second IIgs on the Appletalk network 
> or on the same IIgs as Marinetti?
> 

This would have to be on your $0.99 IIGS that you picked up off of ebay. 
Unfortunately the Localtalk Link Access Protocol (LLAP) rejects packets 
that do not have it's node id in the LLAP packet header and since it 
uses a circular buffer you have to be very quick to get the packet 
before it is overlayed. My first thought is to have a very tight loop 
issuing LAP readbuffer calls and copying out the data but that might not 
work if the firmware only operates on valid packets for this node. In 
that case it'd be more difficult but still should be doable. 


> Cheers,
> Andrew