From: ced@APOLLO.HP.COM (Carl Davidson)
Subject: RE: Need Some Advice...
Date: Thu, 19 Nov 1992 00:53:31 GMT
Organization: Hewlett-Packard Company, Chelmsford, MA
Keywords: atr

In article <BxxJo6.3KH@apollo.hp.com>, giza@apollo.HP.COM (Peter E. Giza) writes:
|> Herb Peyerl Writes:
|> |>If you want to make the assumption that IP packets are encapsulated within 
|> |>DDS packets, then in order to make HP-UX reside on ATR, HP must then have 
|> |>ported DDS to HP-UX on 400's and 700's... That must mean 700's have 
|> |>node-ids. Somehow I doubt that.
|> 
|> 
|> Just for the record.  The ATR cards are same with the exception of
|> few changes for the HP.  The packets are encapsulated in a 73 byte
|> DDS header just like good ole Domain, this is all done at the driver
|> level for the card.  All of the DDS-like behaviour is from the driver
|> there is not a complete DDS port, just enough to make you pregnant.
|> 
|> -peg
|> 
|> Peter E. Giza HP DCE T&D ~:@)

Actually, the ATR card used in Snakes is *exactly* (I know, I spec'd it)
the same one used in the old DPCI-Ring product. That means it's the same
board as used in the DN4XXX-series, but with the Aegis boot PROM removed
and a node ID inserted in the socket that was always there (way back in
the REAL old days, you couldn't even boot an Apollo node without a 
network card in it because then it wouldn't have a node ID to generate
UIDs from, but somewhere along the line we got smart and started putting
them on the system board, but that's another story...). 

As to IP encapsulation on ATR, Pete is right, the entire basic DDS header, 
all *70* bytes of it, is there. It has to be or I'd have broken real
Domain nodes. Right after the DDS header is a little 12 byte header called
the DR header that Domain TCP uses for its own purposes. After that comes 
a conventional IP packet.

I *didn't* port DDS to HP-UX in order to get ATR support into it. That would
have been an extremely time-consuming effort with very little payoff. What I
did do is put enough support in the driver to be able to answer lcnode
(ask_who, ask_who_notopo, and ask_rem_who) requests, as well as ask_time,
ask_bldt, ask_diskless, and ask_node_root. lcnode I *had* to support. 
If I didn't, I'd again break the existing rings these nodes were destined
to go in to. The rest I put in because of the following scenario, which
in my opinion is very common:

    1) lcnode

       long list returned including some uncataloged nodes

    2) bdlt -n NNNNN

       where NNNNN is some uncataloged node's node id
       in this case, it turns out to be an HP-UX node, so we 
       return the same string which would be returned by a
       'uname -a' command

    3) ctnode foobar NNNNN -root

       this puts the node into the Domain NS Helper database
       the next time it is queried with an lcnode

I attempted to violate the "Principle of Least Astonishment" as little
as possible, but as Pete put it, we are "a little bit pregnant." There
are places where this scheme breaks down, such as the 'lcnode -from'
command when run from the other side of a Domain router or when 
the Domain Automount Daemon (damd) tries to make an NFS mount point in
the network root for a node that's already been cataloged this way, but
I figure it's still better than a poke in the eye with a sharp stick.
ATR on HP-UX is only intended to help customers transition from Domain
on ATR to HP-UX on a better network, either FDDI or Ethernet (let's please
not have a religious argument about how Ethernet isn't a better network than
ATR; the market has already decided that one...), not to be used as the 
core network of new installations. 

Well, this got kinda long, but I've been watching this argument fester on 
the net for a while and I just couldn't stay out of it any longer (fools
rush in...). I hope that my explanation helps clear up any questions that
may have been lingering. Even if you don't agree with my implementation
choices, at least now you have some idea why I did it the way I did.

BTW: I'm not the person who maintains this driver nowadays. That's done
     in another division by someone who still does lan drivers for a 
     living, so yelling at me to "FIX IT" won't have much effect. It's 
     not that I'm not sympathetic, but I don't even have access to the 
     code anymore.

Best regards to all of you who still love Domain. With any luck we'll have
something as good again someday.

-- 
Carl Davidson  (508) 436-4361  |
Chelmsford System Software Lab | Microkernels: Where less is more.
The Hewlett-Packard Company    | 
DOMAIN: ced@apollo.hp.com      |
Newsgroups: comp.sys.apollo