Sorry for making a new announcement so close after the previous one, and
the changes are not so great, but I think they are important enough to
send this out right away.
The only thing this release addresses is DECnet over IP:
. First of all, you can now also run DECnet over IP using TCP.
The DECnet over IP implementation have been tested a lot in the last few
days, and some things in the VMS Multinet protocol was not so well
understood by me, and the code did not work very reliably against VMS
for that reason. With the help of Bob Armstrong I've rewritten this code
now, to behave more like VMS does, and my initial testing indicates that
it now works the way it should.
So I'd recommend anyone who is using this feature to upgrade to the
latest version right away.
As usual, the distribution is available from:
ftp://mim.update.uu.se/bqtcp.dsk
ftp://mim.update.uu.se/bqtcp.tap
ftp://ftp.update.uu.se/pub/pdp11/rsx/tcpip/tcpip.dsk
The documentation is also available through ftp on Mim, or also at
http://mim.update.uu.se/tcpipdoc
Note! I've realized that BQTCP/IP do not work right if you have a
PDP-11/74 with multiple processors online. I'll fix that at some point,
as it's probably just a case of affinity not being set on devices, nor
relevant processes. This might only be a problem with telnet in fact. I
know for sure that the IP and TCP drivers works ok in multiprocessor
systems.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
Hi,
I've refrained from asking stupid questions as I've had my crap inactive
for a while (ISP problems mainly), but I'm back to plague you!
Is anyone hosting a DECnet<-->SMTP gateway? I can't get SMTP to work with
my ISP (Virgin Media) from any operating system, but could do with being
about to bounce mail via a machine both ways.
I know it used to work, through LEGATO:: i think, but is this still active?
Thanks,
Tony Blews
Is there anyone who have links between two VMS Multinet machines using
TCP? I would be interested in a tcpdump of the initial packets between
the machines, if anyone could help out...
Johnny
After having my links up and running a couple of days now (and they work
fine), I've come to realize that if we want to have a somewhat efficient
topology, we need to agree on circuit costs.
Now, that said, in todays internet world, network speeds are fast enough
that this isn't really a big problem. So if people don't want to, I'm
okay with that.
But otherwise we should try and use some agreed upon scheme for setting
costs on circuits. The best suggestion I've seen so far is to base it on
ping times. Would people be willing to adopt this and implement it all
over the place for level 2 routers? Because, if not everyone agrees,
then I'm wasting my time here. :-)
The exact cost scale we can discuss, if we agree on doing it. But it
needs to be pretty much used by everyone, or else it's just a waste of
time and energy.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
After a long session of hacking I've gotten both UDP and TCP Multinet
connections working stable in RSX.
And doing this I also realized that I now can automatically handle
people with changing IP addresses, or NAT.
It works automatically with my code. If you have a TCP connection, it
will be dropped if your address changes. If you are the connecting side,
that means it will start trying to reconnect again at that point. And if
I allow connections from anywhere, a new link will be established rather
quickly.
And it also works through NAT.
And if you only have your system online sporadically, that also works fine.
I just figured I should bring this up, for people who have been
searching for solutions for this scenario.
Of course, I do not know if it will work with anything else than RSX,
but I can't fix everything. :-)
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
Ok, so this might be a sensitive subject, after all out mails the last
month.
I figured I should at least try to document and explain how I am setting
costs on my circuits. Others are, of course, free to choose any other
ideas. And DECnet will deal with it, so this only might under some
circumstances make life a little bit better, or worse...
To start with, let me tell you that I run RSX. What I'm writing below
sometimes reflects things under RSX as well, which might not be the same
for other systems.
Now, DECnet have costs. These are "arbitrary" numbers, which DECnet use
to pick which path to prefer when there are several to choose between.
And DECnet do calculations based on the costs of many hops as well, so
the costs I put locally are not the final decider all the time. The
further away the destination is, the more the costs of intermediate hops
matter.
Second, area routing obscures a lot of this. Area routing is separate,
and also works on the same principles.
Now, in RSX, for an area router, I can actually set the cost for both
level one routing, and level two routing, separately. This is not
possible in VMS (as far as I know), so some of the stuff I do will not
be possible in VMS.
Ok, so how do my network look like, and how am I thinking?
Well, first of all, ethernet is mainly a local transport. So, I want to
keep the cost at a level that reflects this. It's cheap and fast. So I
do not want a high cost on it. RSX defaults the cost to 3, and I'm happy
to keep it at that. (I know that VMS defaults to 4.)
Now, this is for level one routing we're talking about.
When it comes to area routing, ethernet is not my preferred choice. It
always means going over the bridge to get to whatever area. If I have a
point-to-point link to that area, I think it is a better choice. So I
want the level two cost to be higher than any direct links. At the
moment, I've set the level two cost on ethernet at Mim to 6.
Point-to-point links will thus have a cost of less than 6 here. And the
actual cost is relative to the physical distance between Mim and that
location. Let's say that other places in Europe might be 1 or 2. US easy
coast 3, and US west coast 5. That should give a fair relative cost of
these links as far as I am concerned.
It also means that unless the US east and west coast have a cost of less
than 2 between them, I should go directly to the east coast, without
hopping through the west coast first. I could, of course, set the costs
equal for all of the US, but then we get to the question, what if I want
to get to a node in the central US? If people in the US put reasonable
costs on their links, the cost should be about equal from the west or
the east to central. If I said my cost to the west and east were equal,
then I could end up going to the west to get to central, which seems the
long way around. And in honesty, the cost from Sweden should be greater
to the west coast than the east coast... it just makes sense to put
honest numbers in there that makes sense.
And if the US east and west puts a cost of 1 to the other end, what cost
is there to central? Also 1. Do they not think one is more expensive
than the other? And if they don't differentiate the costs for such
distances, then either they honestly are just as fast, or else they
might end up jumping through extra hops that do cost, that they maybe
didn't want to.
So my thinking is to put a cost on my point-to-point links that roughly
gives some reflection on how far or slow that link is.
Ethernet is something I mostly want to use for traffic inside my area,
but if someone else only have the bridge, then I'll use ethernet for
that one too.
Remember, no matter how high I put the cost on the ethernet, if it is
traffic within the area, no links to any node in another area will even
be considered, no matter what the cost is.
If you have both the bridge, and ptp links inside the area, then it matters.
If you have both ptp links and bridge to other areas, then cost matters.
Set the cost so that it makes sense. If the bridge generally is the
cheaper/faster/better path, then set the cost lower there. If the ptp
links are better, set the cost accordingly.
With all that said, I've also implicitly given some measurements of what
the costs (for me) reflect. Across all the US costs me about 2. Across
the atlantic about 3. Europe is about 2 across as well.
And for me, ethernet to another area is more expensive than that. But in
most cases, if the hop means a ptp, and then back on the bridge anyway,
then I would hope the cost of the bridge is less. But it will depend, of
course...
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
Sadly, noone seems to be interested in setting up Multinet link. Apart
from the one to LEGATO, not a single one have been set up from MIM so
far. I was hoping for at least SG1 as well.
Meanwhile I've added TCP tunneling in RSX as well, which now works.
I have a question on how Multinet on VMS works, though. When you have
passive TCP connections, are they all sharing the same port number, or
do you configure each with a different number? Right now I did it with
separate port numbers under TCP for each connection, but for incoming
connections, I could change the code to use a common port number.
Any opinions from anyone?
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
Ok. I now have my Multinet circuits set up on MIM. Only UDP at the
moment, but who would like to peer with me, and reduce the size of the
bridge?
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
Well, about a month since my last announcement, and some improvements
have been done, so I figured I should do another one.
I've cut a new release of TCP/IP for RSX, and I encourage everyone to
update to this latest release.
A short list of changes since my last release:
TCP:
. Added functionality for future DECnet tunnels.
UDP:
. Bugfix in write. The second word of the IOSB was always zero, but
should be the number of bytes written. Fixed now.
. Added functionality for DECnet tunnels.
. Improved user AST generation to use less resources.
FTP/FTPD:
. Bugfix in RSX transfer mode, which could become corrupted under some
circumstances.
. Added some more error checking and messages.
TELNET:
. Changed code so that it can properly managed the number of devices to
create. Now controlled by a logical name.
DECnet over IP:
. This is the big change that comes with this release. It is now
possible to have DECnet over IP, in a Multinet-compatible
implementation. Right now, this only works over UDP, but TCP will come
later. There are still probably a couple of rough corners to improve,
but this should be possible to use by anyone, and I have written
documentation for this. I'm very interested to hear someone else try to
install and use it, to find any issues with the installation.
If someone wants to use this, I'm happy to act as a peer for them. Just
let me know.
As usual, the distribution is available from:
ftp://mim.update.uu.se/bqtcp.dsk
ftp://mim.update.uu.se/bqtcp.tap
ftp://ftp.update.uu.se/pub/pdp11/rsx/tcpip/tcpip.dsk
The documentation is also available through ftp on Mim, or also at
http://mim.update.uu.se/tcpipdoc
Note! I've realized that BQTCP/IP do not work right if you have a
PDP-11/74 with multiple processors online. I'll fix that at some point,
as it's probably just a case of affinity not being set on devices, nor
relevant processes. This might only be a problem with telnet in fact. I
know for sure that the IP and TCP drivers works ok in multiprocessor
systems.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
