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
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
-----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
-----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
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.
Johnny
-Steve
------------------------------------------------------------------------
*From:* owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] *On Behalf Of *Ian McLaughlin
*Sent:* Thursday, December 03, 2009 18:56
*To:* hecnet at Update.UU.SE
*Subject:* Re: [HECnet] Others DECnets
Here's where I read about hidden areas:
http://labs.hoffmanlabs.com/node/271
Basically, if you have a network like this:
ME => ROUTER => YOU
Where ME:: and YOU:: are in conflicting areas, and ROUTER:: is a level 1 router between two level 2 routers, you would get from me to you using:
ROUTER::YOU::
I haven't tried it, but it might be worth an experiment.
Ian.
On 2009-12-03, at 3:50 PM, Johnny Billquist wrote:
Hmm. Such a setup will at best be weird.
The level-1 router in the middle, how would it know which way to go when a packet to an area that exist on both sides?
So it would basically only be "useful" when both sides only wanted to talk to the node/area in the middle, and only from nodes for which there were no conflicts.
Or atleast that is my guess, since I haven't actually tried it.
Johnny
Ian McLaughlin wrote:
Maybe a bridge between the two? I read that you can have level-2-router => level-1-router => level-2-router that will allow you to bridge two networks that have conflicting area numbers.
Ian.
On 2009-12-03, at 3:38 PM, Steve Davidson wrote:
What Johnny said... :-)
-Steve
-----Original Message-----
From: owner-hecnet at Update.UU.SE <mailto:owner-hecnet at Update.UU.SE> <mailto:owner-hecnet at Update.UU.SE> [mailto:owner-hecnet at Update.UU.SE] On
Behalf Of Johnny Billquist
Sent: Thursday, December 03, 2009 17:18
To: hecnet at Update.UU.SE <mailto:hecnet at Update.UU.SE> <mailto:hecnet at Update.UU.SE>
Subject: Re: [HECnet] Others DECnets
So, when are you finally going to join HECnet? :-)
Johnny
gerry77 at mail.com <mailto:gerry77 at mail.com> <mailto:gerry77 at mail.com> wrote:
On Sun, 29 Nov 2009 14:56:39 -0500, you wrote:
My version splits out LAT from MOP, adds SCA (LAVc) and LAST
(InfoServer). The LAT/MOP split has been verified to work. LAVc
support is being tested now. The LAST support testing is pending.
I'll take advantage of this message to say that here in this mailing
list
I'm a little bit like an impostor, because in truth I'm not a member
of
HECnet, but of another Hobbyist DECnet based in Italy. :-P
We are now running a quite modified version of Johnny's bridge: we
departed
from his project because some of us have connection and bandwidth
issues
that prevent the development of a strictly star-topology network as
required
by the HECnet bridge. We started experimenting many years ago (in the
2002-2004 timeframe) with Multinet and TCPware tunnels but were not
happy
with that solution because many of us had (and some still have)
dynamic IP
addresses which forced a tunnel recofiguration at every address
change!
At the time, we already did know about HECnet but not about the
bridge,
either because it didn't yet exist or because it was still
unpublished, so
we were forced to abandon out dreams of a DECnet of ours.
About three years ago, in the first days of december 2006, we learnt
about
the bridge and started again our experiments, but we soon understood
that we
were in need of some changes (among other things we had some nasty
packet
loops in the first days), so we asked to Johnny the permission to
modify his
work and here we go: our network is nominally made up of about 30
nodes, all
in the same area, but only three to four are online 24/7, and has a
full
mesh topology, that is every bridge is connected to every other bridge
(but
we later added a feature that allows for mixed topology networks).
If someone is interested in the full feature list and other details,
such as
some DECnet tuning we needed, s/he can contact me off list. :-)
Going back to the original topic, we choose to keep LAT and MOP
together,
and added LAST to the same group of protocols (but we renamed the
.conf
section from [lat] to [lan]). Instead, we didn't ever consider
transporting
SCA across the Internet because it's too much a time-sensitive
protocol and
would be probably almost useless, at least here. Did you succeeded,
Steve,
in keeping on quorum a cluster across the bridge and the Internet?
Cheers,
G.
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se <mailto:bqt at softjar.se> <mailto:bqt at softjar.se> || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
---
Filter service subscribers can train this email as spam or not-spam here: http://my.email-as.net/spamham/cgi-bin/learn.pl?messageid=36125A5AE06511DE8…
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se <mailto:bqt at softjar.se> || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
---
Filter service subscribers can train this email as spam or not-spam here: http://my.email-as.net/spamham/cgi-bin/learn.pl?messageid=A6EBD192E06611DEA…
