On Fri, Dec 04, 2009 at 09:55:47PM -0800, Ian McLaughlin wrote:
You know, all this DECnet routing talk has got me thinking. It's been a
LONG time since I've done any DECnet networking. Is there a good place to
read up on it or should I just read the VMS manuals online since I'll be
doing this from VMS mainly at first.
I spent quite some time trying to get an area router working. I couldn't find any documentation other than the standard DEC manuals (available online). The DEC manuals talk about the theory, including non-routing, level 1 routing and level 2 routing (area routing), but I couldn't find any document that explained how to enable level 2 routing. Thankfully, this list was able to help me out.
Ok, so I'll read the online docs then and use the emails from this list I
saved to setup my L2 router. :)
Thanks!
-brian
--
"Coding in C is like sending a 3 year old to do groceries. You gotta
tell them exactly what you want or you'll end up with a cupboard full of
pop tarts and pancake mix." -- IRC User (http://www.bash.org/?841435)
On 2009-12-04, at 7:23 AM, Brian Hechinger wrote:
You know, all this DECnet routing talk has got me thinking. It's been a
LONG time since I've done any DECnet networking. Is there a good place to
read up on it or should I just read the VMS manuals online since I'll be
doing this from VMS mainly at first.
I spent quite some time trying to get an area router working. I couldn't find any documentation other than the standard DEC manuals (available online). The DEC manuals talk about the theory, including non-routing, level 1 routing and level 2 routing (area routing), but I couldn't find any document that explained how to enable level 2 routing. Thankfully, this list was able to help me out.
Ian.
Paul Koning wrote:
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On
Behalf Of Johnny Billquist
Sent: Friday, December 04, 2009 10:17 AM
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Others DECnets
Hmm, which wouldn't neccesarily result in the same thing...
Named objects use object #0, and then you specify the object name,
which
for instance in RSX means the task name.
Now, I don't even think numbered objects and named ones are handled
the
same way in RSX, since numbered objects are usually in the form
NNN$$$,
where $$$ is replaced by a number, for the service to be able to run
several instances in parallel. I don't think this $$$ replaced by a
number ever is done for named objects.
Also, the name of the task used for a service is not standardized. So,
the mail service task name can be anything. All you know is that it is
#27.
So, trying to talk with an named object called MAIL might cause to you
to talk with just about anything.
In RSX, the known objects of my system looks like this:
.ncp sho kno obj
Known objects summary as of 4-DEC-09 16:07:24
Object Name Copies User Verification
0 Single Default Off
15 TCL... Single Default On
16 LSN$$$ 5 Default Off
17 FAL$$$ 8 Login On
18 HLD... Single Default Off
19 NIC$$$ 5 Default Inspect
23 RMHACP Single Default Off
25 MIR$$$ 5 Default Off
26 EVR$$$ 5 Default Off
27 MAL$$$ 8 Default Off
29 PHO$$$ 5 Default Off
42 RTH Single Default Off
63 DTR... Single Default Off
So, trying to talk to MAIL would simply just fail, unless there is a
MAIL task installed, in which case that will be started. What program
that might be, and what it might do is beyond guess, but most likely
not
what a programmer of a remote system might have expected, if he tried
to
talk to an object called MAIL, thinking that was the right way to talk
with a MAIL-11 server accepting mails.
Good point. The name flavor of object reference is OS specific, because
the conventions for what names appear aren't the same everywhere. So
the numbers provide the portable way. If you use the name form you have
to know what you're dealing with. The example I gave (connect to
"MAIL") would work for DECnet/E.
Yes, it will be OS specific.
But even more so, I don't think it will work out right for you even if you try to talk to MAL$$$ on an RSX system, because RSX will see that MAL$$$ is a prototype task, and is not allowed to run, and will just fail on you.
When you invoke object 27, as I mentioned, DECnet will actually create a copy from the prototype task, and replace $$$ with a number, making an actual task appear, which is started, and which is not a prototype.
Now, I haven't actually tried this, so I could be wrong, and that DECnet-RSX will actually handle the $$$ substitution for named tasks as well, but I don't think it do. I think that is also tied into the "Copies" parameter, which for named tasks is "Single".
Johnny
Yes, except that object numbers are just one byte... ;-)
Johnny
Bob Armstrong wrote:
However, the object identifier in the
connect message can be either a number or a name. So while normal
practice would be to connect to mail by connecting to object 27, it's
also valid to connect to object "MAIL".
FWIW, this is all in the DECnet database (at least on VMS it is) -
$ MCR NCP SHOW KNOWN OBJECTS
will give you a list. You can also use DEFINE/SET to modify the list
$ MCR NCP DEFINE OBJECT foo NUMBER 493
Bob
Right, except that object numbers are one byte so the upper limit is
255.
paul
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On
Behalf Of Bob Armstrong
Sent: Friday, December 04, 2009 10:12 AM
To: hecnet at Update.UU.SE
Subject: RE: [HECnet] Others DECnets
However, the object identifier in the
connect message can be either a number or a name. So while normal
practice would be to connect to mail by connecting to object 27, it's
also valid to connect to object "MAIL".
FWIW, this is all in the DECnet database (at least on VMS it is) -
$ MCR NCP SHOW KNOWN OBJECTS
will give you a list. You can also use DEFINE/SET to modify the list
$ MCR NCP DEFINE OBJECT foo NUMBER 493
Bob
Hi.
Paul Koning wrote:
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On
Behalf Of Johnny Billquist
Sent: Friday, December 04, 2009 6:49 AM
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Others DECnets
Hi.
Steve Davidson wrote:
They used to call that poor-mans-routing (PRM), and yes that is
basically how it worked. ZKO has over 3000 machines and only had
areas
2 and 19. The fix was hidden area support which in this case meant
anything from either 63, or 62. I don't remember if they used areas
61
or 60. I managed machines in area 2, 19 and 63. My area 63 nodes
were
on satellites of clusters (in either area 2 or 19) that has DECnet
aliases Worked very well. For those who were unfortunate to not be
attached to a cluster PMR was the only way to either send mail, or
SET HOST.
Yes, PMR is "well known". :-)
I think I can see how the hidden network idea can work now.
The level one router just needs to have two separate network
interfaces,
and two separate physical networks, and then it could work.
The reason it will work is because DECnet can do a shortcut in some
places, one of them being that a level one router can actually talk
directly to a level two router in another area.
That doesn't sound right. A level 1 router doesn't listen to area route
messages so it doesn't know anything about other areas, or area routers.
Only area routers do such a thing.
Yes. I agree. And I was kindof surprised that they actually do this, but I seem to remember discovering that they actually are doing this as I was trying to isolate areas with my bridge program. My problem was that I set up a filter which prevented traffic from generic machines in one area to send packets over the bridge, only allowing specific machines (level two routers in my case). The experimentation failed, since broadcast messages still were allowed to spill over, and I discovered that machines tried to talk directly with eachother without going through the level two router.
So that idea failed. :-(
But I learned something...
I don't remember the actual setup that was used, but I *think* it was
like this:
The network backbone was built out of area routers that had their max
area set to 62 (or whatever was the highest "real" area). Any area that
contained hidden-area nodes would connect to the backbone with another
area router (or set of them) which have max area set to 63, and all the
other nodes in that site would only connect to these max-63 area
routers. Those area routers could see the local area 63, but the
backbone could not because that's outside the range of area numbers it
was supporting.
So routing works. Say that node 2.2 wants to talk to 63.123. Assume
both are L1 routers for simplicity. 2.2 would send to its nearest area
router, which (by the config rule) has max area 63. So it knows how to
get to the area 63 router. That path is guaranteed not to involve any
backbone routers because those have max area set to 62 so they aren't
offering any path to area 63. The packet gets to the area 63 router,
which delivers to 63.123. The same works in the other direction.
Hmm. That was another intriguing idea... Gotta think a little bit more here.
I only know stuff from what I've observed here. I haven't actually tried making any "hidden" areas.
My effort was basically motivated by my trying to reduce traffic over the bridges, since I could configure my bridge to tell which machines were actually making meaningful data to really pass over the bridge.
I'll be happy to explain in more detail how and why this failed, if people really want to know.
Johnny
paul
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On
Behalf Of Johnny Billquist
Sent: Friday, December 04, 2009 10:17 AM
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Others DECnets
Hmm, which wouldn't neccesarily result in the same thing...
Named objects use object #0, and then you specify the object name,
which
for instance in RSX means the task name.
Now, I don't even think numbered objects and named ones are handled
the
same way in RSX, since numbered objects are usually in the form
NNN$$$,
where $$$ is replaced by a number, for the service to be able to run
several instances in parallel. I don't think this $$$ replaced by a
number ever is done for named objects.
Also, the name of the task used for a service is not standardized. So,
the mail service task name can be anything. All you know is that it is
#27.
So, trying to talk with an named object called MAIL might cause to you
to talk with just about anything.
In RSX, the known objects of my system looks like this:
.ncp sho kno obj
Known objects summary as of 4-DEC-09 16:07:24
Object Name Copies User Verification
0 Single Default Off
15 TCL... Single Default On
16 LSN$$$ 5 Default Off
17 FAL$$$ 8 Login On
18 HLD... Single Default Off
19 NIC$$$ 5 Default Inspect
23 RMHACP Single Default Off
25 MIR$$$ 5 Default Off
26 EVR$$$ 5 Default Off
27 MAL$$$ 8 Default Off
29 PHO$$$ 5 Default Off
42 RTH Single Default Off
63 DTR... Single Default Off
So, trying to talk to MAIL would simply just fail, unless there is a
MAIL task installed, in which case that will be started. What program
that might be, and what it might do is beyond guess, but most likely
not
what a programmer of a remote system might have expected, if he tried
to
talk to an object called MAIL, thinking that was the right way to talk
with a MAIL-11 server accepting mails.
Good point. The name flavor of object reference is OS specific, because
the conventions for what names appear aren't the same everywhere. So
the numbers provide the portable way. If you use the name form you have
to know what you're dealing with. The example I gave (connect to
"MAIL") would work for DECnet/E.
paul
That sounds vaguely right. I wish I could find all my notes on this. I
will keep looking though.
-Steve
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On
Behalf Of Paul Koning
Sent: Friday, December 04, 2009 09:59
To: hecnet at Update.UU.SE
Subject: RE: [HECnet] Others DECnets
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On
Behalf Of Johnny Billquist
Sent: Friday, December 04, 2009 6:49 AM
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Others DECnets
Hi.
Steve Davidson wrote:
They used to call that poor-mans-routing (PRM), and yes that is
basically how it worked. ZKO has over 3000 machines and only had
areas
2 and 19. The fix was hidden area support which in this case meant
anything from either 63, or 62. I don't remember if they used areas
61
or 60. I managed machines in area 2, 19 and 63. My area 63 nodes
were
on satellites of clusters (in either area 2 or 19) that has DECnet
aliases Worked very well. For those who were unfortunate to not be
attached to a cluster PMR was the only way to either send mail, or
SET HOST.
Yes, PMR is "well known". :-)
I think I can see how the hidden network idea can work now.
The level one router just needs to have two separate network
interfaces,
and two separate physical networks, and then it could work.
The reason it will work is because DECnet can do a shortcut in some
places, one of them being that a level one router can actually talk
directly to a level two router in another area.
That doesn't sound right. A level 1 router doesn't listen to area route
messages so it doesn't know anything about other areas, or area routers.
Only area routers do such a thing.
I don't remember the actual setup that was used, but I *think* it was
like this:
The network backbone was built out of area routers that had their max
area set to 62 (or whatever was the highest "real" area). Any area that
contained hidden-area nodes would connect to the backbone with another
area router (or set of them) which have max area set to 63, and all the
other nodes in that site would only connect to these max-63 area
routers. Those area routers could see the local area 63, but the
backbone could not because that's outside the range of area numbers it
was supporting.
So routing works. Say that node 2.2 wants to talk to 63.123. Assume
both are L1 routers for simplicity. 2.2 would send to its nearest area
router, which (by the config rule) has max area 63. So it knows how to
get to the area 63 router. That path is guaranteed not to involve any
backbone routers because those have max area set to 62 so they aren't
offering any path to area 63. The packet gets to the area 63 router,
which delivers to 63.123. The same works in the other direction.
paul
You know, all this DECnet routing talk has got me thinking. It's been a
LONG time since I've done any DECnet networking. Is there a good place to
read up on it or should I just read the VMS manuals online since I'll be
doing this from VMS mainly at first.
Other than that, I should really get a tunnel setup to play with so I'm
ready to go once the new colo server is in place.
-brian
--
"Coding in C is like sending a 3 year old to do groceries. You gotta
tell them exactly what you want or you'll end up with a cupboard full of
pop tarts and pancake mix." -- IRC User (http://www.bash.org/?841435)
Hmm, which wouldn't neccesarily result in the same thing...
Named objects use object #0, and then you specify the object name, which for instance in RSX means the task name.
Now, I don't even think numbered objects and named ones are handled the same way in RSX, since numbered objects are usually in the form NNN$$$, where $$$ is replaced by a number, for the service to be able to run several instances in parallel. I don't think this $$$ replaced by a number ever is done for named objects.
Also, the name of the task used for a service is not standardized. So, the mail service task name can be anything. All you know is that it is #27.
So, trying to talk with an named object called MAIL might cause to you to talk with just about anything.
In RSX, the known objects of my system looks like this:
.ncp sho kno obj
Known objects summary as of 4-DEC-09 16:07:24
Object Name Copies User Verification
0 Single Default Off
15 TCL... Single Default On
16 LSN$$$ 5 Default Off
17 FAL$$$ 8 Login On
18 HLD... Single Default Off
19 NIC$$$ 5 Default Inspect
23 RMHACP Single Default Off
25 MIR$$$ 5 Default Off
26 EVR$$$ 5 Default Off
27 MAL$$$ 8 Default Off
29 PHO$$$ 5 Default Off
42 RTH Single Default Off
63 DTR... Single Default Off
So, trying to talk to MAIL would simply just fail, unless there is a MAIL task installed, in which case that will be started. What program that might be, and what it might do is beyond guess, but most likely not what a programmer of a remote system might have expected, if he tried to talk to an object called MAIL, thinking that was the right way to talk with a MAIL-11 server accepting mails.
Johnny
Paul Koning wrote:
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On
Behalf Of Johnny Billquist
Sent: Friday, December 04, 2009 6:45 AM
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Others DECnets
Hi.
Ian McLaughlin wrote:
Here's where I read about hidden areas:
http://labs.hoffmanlabs.com/node/271
Hmm. Interesting article, although slightly wrong or imprecise
perhaps.
What they refer to as "named objects" are actually numbered objects.
Named objects are the ones which aren't predefined in any way, and are
for random program communications.
For instance, MAIL is never refered to by a name, but instead by it's
number, which is 27. All "well known services" have specific numbers
assigned to them.
Yes and no. It's certainly true that well known services have object
numbers assigned to them (DEC ones are in the range 1-127, and 128-255
are reserved for customer use). However, the object identifier in the
connect message can be either a number or a name. So while normal
practice would be to connect to mail by connecting to object 27, it's
also valid to connect to object "MAIL".
paul
