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...
Johnny
Ian
On 2013-01-29, at 10:45 AM, Johnny Billquist <bqt at softjar.se> wrote:
On 2013-01-29 17:22, Brian Hechinger wrote:
On 1/21/2013 5:36 PM, Dave McGuire wrote:
On 01/21/2013 05:20 PM, Johnny Billquist wrote:
A17RTR:: would work... :)
Hey, that's a good scheme. I will likely do that as well.
Several areas already do that. :-)
Excellent. :-) Would you please remove "GW" at 61.1 and add
"A61RTR" as 61.1023?
Sign me up for that as well.
Please add A52RTR as 52.1023
Done.
Johnny
---
Filter service subscribers can train this email as spam or not-spam here: http://my.email-as.net/spamham/cgi-bin/learn.pl?messageid=0C3058926A4411E28…
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.
paul
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.
Ian
On 2013-01-29, at 10:45 AM, Johnny Billquist <bqt at softjar.se> wrote:
On 2013-01-29 17:22, Brian Hechinger wrote:
On 1/21/2013 5:36 PM, Dave McGuire wrote:
On 01/21/2013 05:20 PM, Johnny Billquist wrote:
A17RTR:: would work... :)
Hey, that's a good scheme. I will likely do that as well.
Several areas already do that. :-)
Excellent. :-) Would you please remove "GW" at 61.1 and add
"A61RTR" as 61.1023?
Sign me up for that as well.
Please add A52RTR as 52.1023
Done.
Johnny
---
Filter service subscribers can train this email as spam or not-spam here: http://my.email-as.net/spamham/cgi-bin/learn.pl?messageid=0C3058926A4411E28…
On 2013-01-29 18:51, Paul_Koning at Dell.com wrote:
Can it handle connections by name, where the changing address is handled through dynamic DNS? If so, you could use dyndns.org or an equivalent service to get a fixed name for your varying address.
The bridge? It only do name resolution at startup and config reload.
Johnny
paul
On Jan 29, 2013, at 12:35 PM, Pete Edwards wrote:
Ok maybe I need to re-phrase the question.
My ISP now only offers me a dynamic IP address.
My understanding is that Johnny's bridge program is not tolerant of
changing IP addresses. Is that still the case?
So based on Sampsa's answer I can connect via a Multinet tunnel and
there's at least one Hecnet member (Steve Davidson) who can keep that
connected even if the IP address changes?
Would that mean I need to move into another area or request an area to myself?
Top-posting on top of a top-posted reply :)
On 29 January 2013 00:30, <sampsa at mac.com> wrote:
Well Steve Davidson has built a system for updating IP addresses of MULTINET circuits - it seems to work pretty well.
sampsa
On 29 Jan 2013, at 02:29, Pete Edwards <stimpy.u.idiot at gmail.com> wrote:
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?
Alas FLETCH (1.100), my VS4000/60 has suffered some kind of disk
trauma during the intervening 2 house moves so it might be a while
before I can connect a physical system.
Nice to see the return of the mapping project too - rather more
elegant than my own short-lived efforts.
Cheers,
Pete
--
Pete Edwards
"There's a man with a mullet going mad with a mallet in Millets!" - HMHB
--
Pete Edwards
"There's a man with a mullet going mad with a mallet in Millets!" - HMHB
On 2013-01-29 18:35, Pete Edwards wrote:
Ok maybe I need to re-phrase the question.
My ISP now only offers me a dynamic IP address.
My understanding is that Johnny's bridge program is not tolerant of
changing IP addresses. Is that still the case?
Correct.
So based on Sampsa's answer I can connect via a Multinet tunnel and
there's at least one Hecnet member (Steve Davidson) who can keep that
connected even if the IP address changes?
Correct.
Would that mean I need to move into another area or request an area to myself?
You need to move to Steve's area, or set one up of your own.
Johnny
Top-posting on top of a top-posted reply :)
On 29 January 2013 00:30, <sampsa at mac.com> wrote:
Well Steve Davidson has built a system for updating IP addresses of MULTINET circuits - it seems to work pretty well.
sampsa
On 29 Jan 2013, at 02:29, Pete Edwards <stimpy.u.idiot at gmail.com> wrote:
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?
Alas FLETCH (1.100), my VS4000/60 has suffered some kind of disk
trauma during the intervening 2 house moves so it might be a while
before I can connect a physical system.
Nice to see the return of the mapping project too - rather more
elegant than my own short-lived efforts.
Cheers,
Pete
--
Pete Edwards
"There's a man with a mullet going mad with a mallet in Millets!" - HMHB
On 2013-01-29 17:22, Brian Hechinger wrote:
On 1/21/2013 5:36 PM, Dave McGuire wrote:
On 01/21/2013 05:20 PM, Johnny Billquist wrote:
A17RTR:: would work... :)
Hey, that's a good scheme. I will likely do that as well.
Several areas already do that. :-)
Excellent. :-) Would you please remove "GW" at 61.1 and add
"A61RTR" as 61.1023?
Sign me up for that as well.
Please add A52RTR as 52.1023
Done.
Johnny
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:
...
Well, the basic "problem" is that there is no http object defined in
DECnet, nor any equivalent to the http protocol, so how would you expect
it to work?
DECnet is not IP, nor TCP.
There are web servers for VMS and I believe you have one running on RSX.
The problem is not one of http but shipping that http over DECnet. Get
the browser and web server speaking DECnet and you're 99% of the way to
the goal.
Certainly there are web servers for both VMS and RSX. None of them (to my knowledge) speaks DECnet. And then you need some browser that also speaks DECnet, and which agrees on the protocol.
There is a problem with the standard http protocol which makes it slightly tricky with DECnet.
http expects to be able to send empty lines. DECnet don't do that. DECnet sends records, and empty records don't get sent at all. I realized this when looking at the MAIL-11 protocol...
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
Can it handle connections by name, where the changing address is handled through dynamic DNS? If so, you could use dyndns.org or an equivalent service to get a fixed name for your varying address.
paul
On Jan 29, 2013, at 12:35 PM, Pete Edwards wrote:
Ok maybe I need to re-phrase the question.
My ISP now only offers me a dynamic IP address.
My understanding is that Johnny's bridge program is not tolerant of
changing IP addresses. Is that still the case?
So based on Sampsa's answer I can connect via a Multinet tunnel and
there's at least one Hecnet member (Steve Davidson) who can keep that
connected even if the IP address changes?
Would that mean I need to move into another area or request an area to myself?
Top-posting on top of a top-posted reply :)
On 29 January 2013 00:30, <sampsa at mac.com> wrote:
Well Steve Davidson has built a system for updating IP addresses of MULTINET circuits - it seems to work pretty well.
sampsa
On 29 Jan 2013, at 02:29, Pete Edwards <stimpy.u.idiot at gmail.com> wrote:
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?
Alas FLETCH (1.100), my VS4000/60 has suffered some kind of disk
trauma during the intervening 2 house moves so it might be a while
before I can connect a physical system.
Nice to see the return of the mapping project too - rather more
elegant than my own short-lived efforts.
Cheers,
Pete
--
Pete Edwards
"There's a man with a mullet going mad with a mallet in Millets!" - HMHB
--
Pete Edwards
"There's a man with a mullet going mad with a mallet in Millets!" - HMHB
Ok maybe I need to re-phrase the question.
My ISP now only offers me a dynamic IP address.
My understanding is that Johnny's bridge program is not tolerant of
changing IP addresses. Is that still the case?
So based on Sampsa's answer I can connect via a Multinet tunnel and
there's at least one Hecnet member (Steve Davidson) who can keep that
connected even if the IP address changes?
Would that mean I need to move into another area or request an area to myself?
Top-posting on top of a top-posted reply :)
On 29 January 2013 00:30, <sampsa at mac.com> wrote:
Well Steve Davidson has built a system for updating IP addresses of MULTINET circuits - it seems to work pretty well.
sampsa
On 29 Jan 2013, at 02:29, Pete Edwards <stimpy.u.idiot at gmail.com> wrote:
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?
Alas FLETCH (1.100), my VS4000/60 has suffered some kind of disk
trauma during the intervening 2 house moves so it might be a while
before I can connect a physical system.
Nice to see the return of the mapping project too - rather more
elegant than my own short-lived efforts.
Cheers,
Pete
--
Pete Edwards
"There's a man with a mullet going mad with a mallet in Millets!" - HMHB
--
Pete Edwards
"There's a man with a mullet going mad with a mallet in Millets!" - HMHB
On 1/21/2013 5:36 PM, Dave McGuire wrote:
On 01/21/2013 05:20 PM, Johnny Billquist wrote:
A17RTR:: would work... :)
Hey, that's a good scheme. I will likely do that as well.
Several areas already do that. :-)
Excellent. :-) Would you please remove "GW" at 61.1 and add "A61RTR" as 61.1023?
Sign me up for that as well.
Please add A52RTR as 52.1023
-brian
