Mike,
I will be ready at this end when you are.
-Steve
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE] On Behalf Of Michael Holmes
Sent: Tuesday, January 29, 2013 11:05
To: hecnet at Update.UU.SE
Subject: RE: [HECnet] New HECnet Area Request
Thanks Johnny.
Steve,
I just got the OS installed late last night, so please be patient as I'll need to go and get the multinet SW and hobbyist license and before I can attempt to connect.
Once I get it all setup I'll send you my IP address and info to test a connection.
thanks.
> Date: Tue, 29 Jan 2013 16:51:05 +0100
> From: bqt at softjar.se
> To: hecnet at Update.UU.SE
> CC: jeep at scshome.net; mholmes10 at hotmail.com
> Subject: Re: [HECnet] New HECnet Area Request
>
> Mike, I'm putting area 39 to your name. Will Steve work for your connection?
>
> Johnny
>
> On 2013-01-29 11:55, Steve Davidson wrote:
> > Mike,
> >
> > Area 39 is available. If you decide to use Multinet Tunnels then configure it to connect to 69.21.253.158 and send me mail with your IP address. If it is a dynamic IP address then I will need to know the domain as well.
> >
> > -Steve
> >
> > ________________________________
> >
> > From: owner-hecnet at Update.UU.SE on behalf of Michael Holmes
> > Sent: Mon 1/28/2013 18:42
> > To: hecnet at Update.UU.SE
> > Subject: [HECnet] New HECnet Area Request
> >
> >
> >
> > Hi all,
> >
> > My alphaserver 800 finally arrived and I'm setting it up now and would like to request a HECNET area so I experiment with connecting to HECNET.
> >
> > I saw a previous message listing available areas and I'd like to request area 39 if its not already spoken for.
> >
> > I finally found a SCSI drive that will work in it and am currently installing VMS 8.3 and DECNET IV on it right now.
> >
> > Hopefully will have it finished tonight and be able work on the HECNET options (router, etc) through the week and weekend.
> >
> > I also have a DEC 3000L and a multia that I'll try to bring back to life sometime later.
> >
> > Thanks
> >
> > Mike
> >
> > Alexandria, VA
> >
> >
> >
>
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE]
On Behalf Of sampsa at mac.com
Sent: 29 January 2013 23:25
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Returning to HECNET
2. Persuade someone who has a fixed IP to run the user mode router,
if you register your IP with something like DynDns then the user
mode router periodically checks for a change of IP.
Is the user mode router ready? I could deploy that..
[Rob Jarratt]
It has been used in a couple of configurations now and seems to work
OK, I use it permanently now. You could try it and if it does not work
for you it is only seconds to switch back to the bridge.
Oh I was going to run the bridge as well, act as a sort of connections hub
(Bridge, MULTINET on GORVAX and the user mode router).
What OS does the user mode router run on?
sampsa
It runs on Windows (as a Windows Service) and it runs on linux (as a
Daemon). I built the linux version on the Raspberry Pi using a flavour of
Debian. I think it has been built on FreeBSD too.
Regards
Rob
2. Persuade someone who has a fixed IP to run the user mode router, if
you register your IP with something like DynDns then the user mode
router periodically checks for a change of IP.
Is the user mode router ready? I could deploy that..
[Rob Jarratt]
It has been used in a couple of configurations now and seems to work OK, I
use it permanently now. You could try it and if it does not work for you it
is only seconds to switch back to the bridge.
Oh I was going to run the bridge as well, act as a sort of connections hub (Bridge, MULTINET on GORVAX and the user mode router).
What OS does the user mode router run on?
sampsa
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE]
On Behalf Of sampsa at mac.com
Sent: 29 January 2013 23:07
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Returning to HECNET
2. Persuade someone who has a fixed IP to run the user mode router, if
you register your IP with something like DynDns then the user mode
router periodically checks for a change of IP.
Is the user mode router ready? I could deploy that..
[Rob Jarratt]
It has been used in a couple of configurations now and seems to work OK, I
use it permanently now. You could try it and if it does not work for you it
is only seconds to switch back to the bridge.
Regards
Rob
2. Persuade someone who has a fixed IP to run the user mode router, if you
register your IP with something like DynDns then the user mode router
periodically checks for a change of IP.
Is the user mode router ready? I could deploy that..
-----Original Message-----
From: owner-hecnet at Update.UU.SE [mailto:owner-hecnet at Update.UU.SE]
On Behalf Of Pete Edwards
Sent: 29 January 2013 00:29
To: hecnet at update.uu.se
Subject: [HECnet] Returning to HECNET
Hi All,
After a rather suddenly enforced break over 2 years ago I'm in a position
where I can try and get back onto HECNET.
I've renewed my VMS PAKs and have a couple of simh VMS 7.3 instances up
again.
Unfortunately when I dropped off back then I lost my static IP, so step
one, I
guess, is asking this: What are the current best options the group has
found
to deal with dynamic addresses?
[Rob Jarratt]
A couple of other options are:
1. Never switch off your router so that it keeps its IP address. In my case
(Virgin Media in the UK), my IP address does not change for months at a
time, and just ask Johnny (or whoever you peer to), to restart the bridge
with a new IP.
2. Persuade someone who has a fixed IP to run the user mode router, if you
register your IP with something like DynDns then the user mode router
periodically checks for a change of IP.
3. Use the upcoming SIMH emulation of the DMC11, which allows you to connect
using TCP to someone else who has a fixed IP. Again you would need to
persuade someone who has a static IP to peer with you. But the SIMH
emulation does actually do a fresh DNS lookup if the connection goes down,
so a change of IP would work in any case.
Regards
Rob
On 2013-01-29 20:25, Ian McLaughlin wrote:
On 2013-01-29, at 10:53 AM, Johnny Billquist <bqt at softjar.se> wrote:
On 2013-01-29 19:48, Ian McLaughlin wrote:
Johnny
Did you manage to fix the problem with mim not reporting the full node list? It's about time I grabbed an updated copy (with all of the new additions) but I didn't want to grab something that was corrupt.
I've been fighting MIM about that, but for some reason it just will not cooperate. I have two solutons for you:
1. Copy each area as individual commands (MIM knows it all, it just seems that the list of known nodes does not list all known nodes now. Bug in NCP methinks at this point...)
2. Grab MIM::US:[DECNET]FIX.CMD which contains all the DEFINE commands for NCP for all the nodes, and run it in NCP on your machine.
I can create command files in other formats easily if there are any special requests. Just let me know...
Is it possible that there's just too many nodes on HECnet? Maybe overflowing a counter somewhere? Have we hit 256 nodes?
We're close to 500 nodes. Long time since we passed 256. :-)
Johnny
On 2013-01-29, at 10:53 AM, Johnny Billquist <bqt at softjar.se> wrote:
On 2013-01-29 19:48, Ian McLaughlin wrote:
Johnny
Did you manage to fix the problem with mim not reporting the full node list? It's about time I grabbed an updated copy (with all of the new additions) but I didn't want to grab something that was corrupt.
I've been fighting MIM about that, but for some reason it just will not cooperate. I have two solutons for you:
1. Copy each area as individual commands (MIM knows it all, it just seems that the list of known nodes does not list all known nodes now. Bug in NCP methinks at this point...)
2. Grab MIM::US:[DECNET]FIX.CMD which contains all the DEFINE commands for NCP for all the nodes, and run it in NCP on your machine.
I can create command files in other formats easily if there are any special requests. Just let me know...
Is it possible that there's just too many nodes on HECnet? Maybe overflowing a counter somewhere? Have we hit 256 nodes?
Ian
On Jan 29, 2013, at 2:02 PM, Johnny Billquist wrote:
...
Protocol wise, you could (I guess) just decide to append a CR+LF to each record sent, and then strip those off at the receiving side before processing the data. But that is a protocol change, as these would need to be explicitly added and removed inside the packets sent in DECnet. Also, I guess each packet would be a full line, although doing data merging of packets on the receiving side to get lines could also be done.
Well, actually, http already specifies the CF+LF on each record. The issue is the implicit extra information received by doing packets instead of a stream, but you could just ignore the record metadata, and look at it as a stream of bytes. It does, however, still force you to define that this is how http should be done on top of DECnet, which today is not "defined".
I think you're making this more complicated than it needs to be. DECnet has SDU (message) boundaries, TCP does not. So TCP based protocols do not use message boundaries, they are byte streams. If you want to carry a TCP-origin protocol over DECnet, put the stream into DECnet messages without any regard to message boundaries (other than any size limits). For received messages, ignore the message boundaries.
I think that's basically what a stream mode DECnet socket on Ultrix is defined to do. So I'm basically saying that the mapping of http onto DECnet is "use stream mode, object number 80" -- that's basically the whole description.
paul
On 2013-01-29 19:49, Paul_Koning at Dell.com wrote:
On Jan 29, 2013, at 1:44 PM, Johnny Billquist wrote:
On 2013-01-29 16:52, Paul_Koning at Dell.com wrote:
On Jan 29, 2013, at 10:43 AM, Johnny Billquist wrote:
On 2013-01-29 15:36, Brian Schenkenberger, VAXman- wrote:
Johnny Billquist <bqt at softjar.se> writes:
...
So we'd need to do some changes to the http protocol to adopt it on DECnet...
Johnny
That should be completely trivial. First, you assign an object number (pick a number -- 80 would be an obvious choice). Then you send the data across a DECnet connection. That too is easy. Yes, DECnet sends packets, not just a dumb byte stream. So it has structure, IF you need it. If you don't, just pour the bytes into the packets and send them. Ultrix does that -- its DECnet sockets have both a packet and a stream mode. I'm not entirely sure how stream mode behaves; my guess would be that it just sticks the stream into packets whichever way is convenient.
As for the blank lines, that's not an issue. A blank line is \r\n (or maybe just \n) but it certainly is not a null string. So an HTTP request would live inside a packet that contains the text of the request, WITH the newline characters.
Well, I don't expect there to be much work, but it will also not be just a search and replace of a bunch of calls.
Anyway, if anyone ever want to actually do it, we can talk details.
It would be fairly straight forward to adapt my server to talk DECnet.
Johnny
I was talking about changes needed at the protocol level. The API level is a different question, that depends on the OS. For example, on Ultrix and Linux it should be no harder than the protocol changes since both support DECnet sockets. On other operating systems, the simplest port might be to fake up a "decnet socket" library, so the main program code won't see the rather different API used to talk to DECnet. Hardest would be RSTS because it expects applications to do the NSP message segmentation and reassembly rather than doing it in the kernel as is done by most other operating systems.
I was actually talking about protocol changes as well, as if it had only been API changes, then it would have been trivial (well, as far as just changing from TCP to DECnet can ever be trivial).
Protocol wise, you could (I guess) just decide to append a CR+LF to each record sent, and then strip those off at the receiving side before processing the data. But that is a protocol change, as these would need to be explicitly added and removed inside the packets sent in DECnet. Also, I guess each packet would be a full line, although doing data merging of packets on the receiving side to get lines could also be done.
Well, actually, http already specifies the CF+LF on each record. The issue is the implicit extra information received by doing packets instead of a stream, but you could just ignore the record metadata, and look at it as a stream of bytes. It does, however, still force you to define that this is how http should be done on top of DECnet, which today is not "defined".
Like I said, I became aware of the issues when doing some MAIL-11 stuff. MAIL-11 sends each line of a mail, as well as various control information in records. It's implied that there are a newline after each record when we talk about the mail body.
The TCP interface in RSX is just a device, which makes it pretty trivial to write code that talks TCP/IP. Changing to DECnet means removing all the nice and easy PRINT and INPUT lines, and instead call explicit DECnet send and receive functions.
Johnny
