On Sat, 26 Nov 2011 02:35:17 -0500, you wrote:
3) and from what I remember, they are entirely dynamic DNS based and
thus had to make major changes to the bridge to even exist.
The changes they made work just fine, BTW...
Back then we were entirely dynamic and our network had a full mesh topology.
Now we have both static and dynamic addresses and the network has a full
mesh core plus some "forward legs" speaking only to the nearest core node.
We had and we still have some bandwith and latency issues, especially on
leaf nodes. Because of that, our standard setup has a 90 seconds hello timer
(instead of the default 15 seconds). The same for the multicast LAT timer.
We also had some UDP fragmentation issues with some ISPs, probably due to
their sloppy IP router configurations, or something similar. That is, some
ISPs had (and maybe have) problems transporting UDP payloads that cause the
full UDP packet to exceed the standard Ethernet frame size. We absolutely do
not know why, but we discovered it during long and boring trial-and-error
sessions. Our solution was to reduce the DECnet buffer size from 1498 bytes
down to 1456 or even 1428, so that a full DECnet frame plus the UDP packet
overhead totals to something less than 1500 bytes. It's a tradeoff that pays
very well on the side of DECnet reliability and robustness.
HTH,
G.
On Sat, 26 Nov 2011 12:05:30 +0100, you wrote:
networks. "Ownership" of area 1 may possibly have ego involved though I
doubt that Johnny would care much.
That's not our case. We just picked area 1 because it was the most "natural"
choice. At first many of us didn't bother about DECnet at all and choose the
first available value, i.e. 1.1. Then, when we started dreaming and thinking
about a network, we started choosing address ranges in the 1.1 to 1.1023
range: one location from 1.1 to 1.9, another from 1.10 to 1.19, and so on.
Each location (not always a physical one) was assigned to an administrator,
and when that administrator filled its ten-addresses range, it received an
additional one, not always contiguous to the previous. When the network
became reality we implicitly choose to keep that numbering standard.
We have also a few exceptions: the first was our Simh VAX/VMS V4.7 node that
earned 1.666 because was evil to set up to our needs; the other is 1.1010
for the TOPS-10 node which also got DIECI as its node name (because dieci is
the italian word for ten: compare it to decem in latin).
There was a time when we considered changing our area number to 39 (the
international dial code for Italy), but then there was really no need to do
that and some members of our network are somewhat difficult to reach and
speak with, so we would have ended with a mixture of areas 1 and 39, and
that led to the cancellation of the renumbering project.
When you, Hans, renumbered your systems, you were just one single person
renumbering his personal nodes, under your direct control. We are in a
situation which is more like asking the whole HECnet (or a major part of it)
to change numbers.
In another message on this thread I have posted a link to our node list. In
that list there is a column showing the administrator nickname for every
node. Well, that column does not tell the real story: there is a good number
of nodes administered by one person, but physically located remotely from
that person. Some nodes are active, but some others are switched off and do
come online from time to time, without prior advice and it's not so easy to
tell the relevant people to remember not to come online without prior
intervention from some of us in order to change the DECnet address. So, go
figure what would happen if someone comes online with e.g. the MIM address.
What I've read about the "enhancements" to the bridge program is yet another
matter. First off, it ain't called bridge for nothing: like any layer 2
bridge the program moves packets between ports and is transparent to both
the content of the datagrams and the functionality of the protocol.
Including DNS like functionality violates that rule.
In my opinion, if anyone wants a central name repository for DECnet please
upgrade to DECnet phase V.
Which is my way of saying that I'm not too fond of this "enhancement"...
I think you have misunderstood our DNS functionality. Our bridge just tries
to resolve bridge endpoint IP addresses, but it is completely DECnet
transparent, i.e. it does not and never did try to resolve DECnet node names
into DECnet addresses. That's a service specific to DECnet Phase V, as you
correctly appear to suggest.
If our bridge does not receive anything (that is neither data nor even a
hello packet) from an endpoint defined as dynamic, after a certain amount of
time it tries to resolve again the hostname of that endpoint only.
Because our bridges are transmitting and receiving most of the time, the
resolve routine gets called quite seldom, so the delay issues explained by
Johnny may be encountered as seldom as an IP address change, and we consider
it a honest "price" to pay to have automatic dynamic IP addresses working.
Bye,
G.
P.S. please, forgive any syntax or grammar error: I'm not English native.
On Sat, 26 Nov 2011 06:37:02 -0800, you wrote:
P.S. Does anybody have a list of the nodes on the Italian network?
You may want to check http://decnet.ipv7.net
In particular http://decnet.ipv7.net/nodetab-en.html for the node list and
http://decnet.ipv7.net/soft-en.html for our modified bridge software.
There is also http://decnet.ipv7.net/gatetab-en.html for Internet gateways
to our network, complete with guest user names :)
Note also that some other nodes may have guest access, even if not directly
reachable from the Internet, such as the VAX/VMS V4.7 and the TOPS-10 nodes.
G.
On Sat, 26 Nov 2011 02:02:20 +0000, you wrote:
I've been thinking that it's a bit silly to have two separate hobby DECNETs,
so I figured we should get connected to the Italian net as well.
Any ideas?
In truth, HECnet and the Italian DECnet network are not alone: we were made
aware of at least another similar Croatian-based project named SLON (the
Croatian word for elephant and also the name of the SLOvenska Network in the
SPAN/HEPnet time-frame). They started experimenting with Multinet tunnels
and then maybe switched to our fork of Johnny's bridge. But we haven't heard
anything from them since years, and we have no way to contact them either,
so I cannot say for sure if they are still doing something or if they are in
deep sleep since then. Unfortunately, the name they gave to their project is
really not a good choice for Google lookups...
HTH,
G.
(I'm one of the guys from the Italian DECnet)
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On
Behalf Of hvlems at zonnet.nl
Sent: Sunday, November 27, 2011 9:44 PM
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Linker warnings
It's very good to read the words 'I'm new to VMS'.
Hopefully you enjoy the ride!
It's amazing, thank you!
It's very good to read the words 'I'm new to VMS'.
Hopefully you enjoy the ride!
-----Original Message-----
From: "Pinoccio" <pinoccio at gmx.com>
Sender: owner-hecnet at Update.UU.SE
Date: Sun, 27 Nov 2011 21:34:04
To: <hecnet at Update.UU.SE>
Reply-To: hecnet at Update.UU.SESubject: RE: [HECnet] Linker warnings
Thank you!
I am new to VMS so some of its useful facilities (as HELP /MESSAGE) not yet
known to me.
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf
Of Peter Coghlan
Sent: Sunday, November 27, 2011 9:17 PM
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Linker warnings
Can anyone bring some light on these linker warnings:
%LINK-W-TRUNC, truncation error in psect CODE offset %X0000046C
in module XXX file YYY
-LINK-W-TRUNCDAT, computed value is %X00000080
value written is %XFFFFFF80 at location %X0000A2B8
Assuming this is VMS, $ HELP /MESSAGE says:
TRUNCDAT, computed value is 'value1'
value written is 'value2' at location 'address'
Facility: LINK, Linker Utility
Explanation: Usually, this error occurs when a reference using byte or
word PC-relative displacement is made to a target requiring
longword relative displacement. 'Value1' is the value the
linker needed to store; 'value2' is the value the linker is
able to store (a truncated version).
User Action: Correct the reference to use longword relative addressing
mode.
For something more specific, it would help to know more background.
Regards,
Peter Coghlan.
Thank you!
I am new to VMS so some of its useful facilities (as HELP /MESSAGE) not yet
known to me.
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf
Of Peter Coghlan
Sent: Sunday, November 27, 2011 9:17 PM
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Linker warnings
Can anyone bring some light on these linker warnings:
%LINK-W-TRUNC, truncation error in psect CODE offset %X0000046C
in module XXX file YYY
-LINK-W-TRUNCDAT, computed value is %X00000080
value written is %XFFFFFF80 at location %X0000A2B8
Assuming this is VMS, $ HELP /MESSAGE says:
TRUNCDAT, computed value is 'value1'
value written is 'value2' at location 'address'
Facility: LINK, Linker Utility
Explanation: Usually, this error occurs when a reference using byte or
word PC-relative displacement is made to a target requiring
longword relative displacement. 'Value1' is the value the
linker needed to store; 'value2' is the value the linker is
able to store (a truncated version).
User Action: Correct the reference to use longword relative addressing
mode.
For something more specific, it would help to know more background.
Regards,
Peter Coghlan.
Can anyone bring some light on these linker warnings:
%LINK-W-TRUNC, truncation error in psect CODE offset %X0000046C
in module XXX file YYY
-LINK-W-TRUNCDAT, computed value is %X00000080
value written is %XFFFFFF80 at location %X0000A2B8
Assuming this is VMS, $ HELP /MESSAGE says:
TRUNCDAT, computed value is 'value1'
value written is 'value2' at location 'address'
Facility: LINK, Linker Utility
Explanation: Usually, this error occurs when a reference using byte or
word PC-relative displacement is made to a target requiring
longword relative displacement. 'Value1' is the value the
linker needed to store; 'value2' is the value the linker is
able to store (a truncated version).
User Action: Correct the reference to use longword relative addressing
mode.
For something more specific, it would help to know more background.
Regards,
Peter Coghlan.
Hi all!
Can anyone bring some light on these linker warnings:
%LINK-W-TRUNC, truncation error in psect CODE offset %X0000046C
in module XXX file YYY
-LINK-W-TRUNCDAT, computed value is %X00000080
value written is %XFFFFFF80 at location %X0000A2B8
Thanks.
He is on this mailinglist...
Johnny
On 2011-11-26 19.11, Steve Davidson wrote:
Send a mail message to:
gerry77 at mail.com
He should be able to provide you with a list of nodenames (and
addresses).
-Steve
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On
Behalf Of Johnny Billquist
Sent: Saturday, November 26, 2011 11:25 AM
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Integrating with the Italian network.
On 2011-11-26 15:37, Bob Armstrong wrote:
Johnny wrote:
That is not really a big issue. DECnet do not have a requirement for
a coherent nodename database. Every machine can have its own.
This is technically true, but it's really not very useful to have a
network with duplicate node names. After all, if I post a message
saying "phone me on ABC::" or "copy these files from XYZ::" and half
the users have a different ABC or XYZ, then people are not going to be
happy.
Yeah. That is very true. However, you could just have a subset that is
"common", and then have your own names for local machines that noone
else cares about, and name conflict between such machines wouldn't be an
issue.
But that is up to people to decide how they want it. I like it better to
have a global name space, and all my machines pick the nodename database
from MIM so I have them as much in synch as possible. I occasionally
also ping people when I notice nodes for which I have no name, but from
which communication have been visible.
Sure, it may be that the Italian guys never access our nodes and
vice versa, but if that's true then what's the point in integrating?
Yup.
P.S. Does anybody have a list of the nodes on the Italian network?
I can probably get a list... But how about exploring if they'd be
interested in hooking up first maybe?
Johnny
