PDP-10
Implement Chaosnet broadcast sending
ITS learns how to send BRD packets. Note that it is slightly different from the spec (MIT AIM 628 Sec 4.5) in that BRD packets are retransmitted by ITS, and only ANS responses are delivered to the user, until the user closes the channel. This requires some discipline of the user, to use reasonably short timeouts and closing the channel. Often you also need to use an interrupt routine to detect incoming packets, since NETBLK isn't useful.
Two example programs are included: CHATST gets a new "BRD" command, and NAME learns to use broadcast for the /L switch ("associated lisp machines") and for the *LISPM ("all lispms") JCL (note: not @*LISPM). The /L switch uses broadcast on the local subnet, while *LISPM uses global broadcast.
PEEK learns to show the Broadcast-sent (or BRDSNT) state of Chaosnet connections.
(For klh10 using ifmeth=chudp, the most recent version of klh10 is required in order for broadcast packets to actually be sent on chudp links. For ifmeth=pcap, it works also on older versions.)
Future work:
- copy code from NAME to NAMDRG, to solve issue #2195 (but since I don't have a TV setup, someone else might want to do this? It should be mainly copy/paste.)
- implement broadcast
TIMEchecking - teach NAME to show free lisp machines
- teach NAME to broadcast using the
LOADprotocol, and for responses withUsers: nfor n>0, connect with theNAMEprotocol and show who's on.
Acknowledgement: Many thanks to @larsbrinkhoff for the new mlftp program, which increased productivity! (See branch of https://github.com/Chaosnet/chaosnet-tools.)
Very nice!
copy code from NAME to NAMDRG, to solve issue #2195
My only known issue with NAMDRG not finding free Lispms is that there are none on the network. Can you explain how NAMDRG worked or didn't work before, and how broadcasting would impact that?
Very nice!
copy code from NAME to NAMDRG, to solve issue #2195
My only known issue with NAMDRG not finding free Lispms is that there are none on the network. Can you explain how NAMDRG worked or didn't work before, and how broadcasting would impact that?
Without broadcast, NAMDRG would need to know (hardwired in the code) all lispms that might be free or not. With broadcast, they respond whereever they are (with up-to-date code running, which is now "years old").
But I'm seriously considering marking this PR as "draft" until I played^Wexperiemented more with manual retransmissions. It might not be as awkward as I imagined.
But I'm seriously considering marking this PR as "draft" until I played^Wexperiemented more with manual retransmissions. It might not be as awkward as I imagined.
There. It wasn't all that awkward.
Does the simh implementation of CH11 (and CH10?) implement broadcast over CHUDP?
No, the SIMH variants don't do any broadcasting.
But if I read the docs correctly, all it does is broadcasting - i.e. it sends all packets to its (single) peer? The code doesn't seem to even look at the destination address. So then this PR "should work" also on simh-based systems? Anyone, please try?
In that case, yes of course they all do broadcast!
@eswenson1 you have several SIMH emulators on a single Chaosnet segment, right?
Yes, I have KLH10 (2) and one each of pdp10-kl, ka, and ks.
what ca I do to test? (Or feel free to use them).
Yes, I have KLH10 (2) and one each of pdp10-kl, ka, and ks.
what ca I do to test? (Or feel free to use them).
If you use the new system;chaos > to build a new ITS, boot it, then compile the new chatst, and use bRD FINGER and see if you get replies?
On EXA (pdp10-ka), I get:
EXA>:chatst
>BRD Contact name: finger
Now sending: OP 16 BRD, FC 0., NB 38.
From 0-0 to 0-0
Pkt # 0, ack # 40
Data: "······························finger"
Sending...
Have packets: 0
More packets: 0
Now sending: OP 16 BRD, FC 0., NB 38.
From 0-0 to 0-0
Pkt # 0, ack # 40
Data: "······························finger"
Sending...
Have packets: 0
Timed out
Closing and reopening channels
>
On EXL (pdp10-kl), I get:
EXL>:chatst
>BRD Contact name: finger
Now sending: OP 16 BRD, FC 0., NB 38.
From 0-0 to 0-0
Pkt # 0, ack # 40
Data: "······························finger"
*** IOC ERROR *** Channel=13, PC=4037
State is now Closed
Input count=0., Output count=0.
Input window=8., Output window=0.
Dismissing...
ERROR: PKTIOT: DEVICE FULL
4037>>.CALL 6062 (PKTIOT)
Note: I can do a ":FINGER EXA" and get a good response, and I did "supdup" to EXL, so I know it is "on" the chaosnet and that the chaosnet is working.
On EXS (pdp10-ks), I get:
:chatst
>BRD Contact name: finger
Now sending: OP 16 BRD, FC 0., NB 38.
From 0-0 to 0-0
Pkt # 0, ack # 40
Data: "······························finger"
Sending...
Have packets: 0
More packets: 0
Now sending: OP 16 BRD, FC 0., NB 38.
From 0-0 to 0-0
Pkt # 0, ack # 40
Data: "······························finger"
Sending...
Have packets: 0
More packets: 0
Now sending: OP 16 BRD, FC 0., NB 38.
From 0-0 to 0-0
Pkt # 0, ack # 40
Data: "······························finger"
Sending...
Have packets: 0
Timed out
Closing and reopening channels
>
For EX (klh10), I get:
chatst↑K!
>BRD Contact name: finger
Now sending: OP 16 BRD, FC 0., NB 38.
From 0-0 to 0-0
Pkt # 0, ack # 40
Data: "······························finger"
Sending...
Have packets: 0
More packets: 0
Now sending: OP 16 BRD, FC 0., NB 38.
From 0-0 to 0-0
Pkt # 0, ack # 40
Data: "······························finger"
Sending...
Have packets: 0
More packets: 0
Now sending: OP 16 BRD, FC 0., NB 38.
From 0-0 to 0-0
Pkt # 0, ack # 40
Data: "······························finger"
Sending...
Have packets: 0
Timed out
Closing and reopening channels
>
Note: I have not updated KLH10 with the patch you referenced somewhere. Do I need/want to?
Note: I have not updated KLH10 with the patch you referenced somewhere. Do I need/want to?
Yes, for KLH10 with chudp you need the bleeding edge version, which is now in the master branch.
I realize a better test is BRD LOAD since CHATST does broadcast on the local subnet, and you don't have anyone answering FINGER. You do have LOAD servers on ES, EX and EXL though. You could try editing CHATST at mkbmsk to make it do global broadcast; then FINGER should work too.
I should have finger servers on all those machines. However, since your instructions said to rebuild ITS, build the updated CHARST, and run it, I hadn’t rebuilt NAME/PEEK and neither had been purified and updated against the new ITS.
I’ve since updated NAME and PEEK. Should I rerun the test?
It's confusing, but the Chaosnet FINGER protocol is not what is used by :FINGER (:F, :NAME etc) - it uses the NAME protocol. FINGER is used by Lisp machines (and my iMac).
Please rerun the test, but with the LOAD contact name instead?
I reran on EXA. Got this:
Mysterious. After trying to build a pdp10-ka ITS by cloning the repo and doing make EMULATOR=pdp10-ka all, which stops with The last command timed out., I realised make EMULATOR=pdp10-ka download was a lot easier. Then I configured a Chaosnet address on my subnet 7, copied system;chaos > from BV, rebuilt ITS and rebooted, and copied bv;chatst > from BV, compiled it and ran it.
It seems to work fine. I think you have bad luck? ;-) But maybe I should try configuring a new subnet and see what happens.
At some point I will give some feedback on the build process, and patch ITS to handle the situation where the CH10 "CHAOSNET ADDRESS SWITCHES ARE SET WRONG" (and, like for CH11, simply use the address from the interface, so you don't have to recompile ITS to change addresses).
I tried on EXS and got this:
chatst↑K!
>BRD Contact name: load
Now sending: OP 16 BRD, FC 0., NB 36.
From 0-0 to 0-0
Pkt # 0, ack # 40
Data: "······························load"
Sending...
Have packets: 0
More packets: 0
Now sending: OP 16 BRD, FC 0., NB 36.
From 0-0 to 0-0
Pkt # 0, ack # 40
Data: "······························load"
Sending...
Have packets: 0
More packets: 0
Now sending: OP 16 BRD, FC 0., NB 36.
From 0-0 to 0-0
Pkt # 0, ack # 40
Data: "······························load"
Sending...
Have packets: 0
Timed out
Closing and reopening channels
>
And I tried on EXL and got this:
↑Kchatst!
>BRD Contact name: load
Now sending: OP 16 BRD, FC 0., NB 36.
From 0-0 to 0-0
Pkt # 0, ack # 40
Data: "······························load"
Sending...
Have packets: 0
More packets: 0
Now sending: OP 16 BRD, FC 0., NB 36.
From 0-0 to 0-0
Pkt # 0, ack # 40
Data: "······························load"
Sending...
Have packets: 0
More packets: 0
Now sending: OP 16 BRD, FC 0., NB 36.
From 0-0 to 0-0
Pkt # 0, ack # 40
Data: "······························load"
Sending...
Have packets: 0
Timed out
Closing and reopening channels
>
Retried on EXA and got this:
chatst↑K!
>BRD Contact name: load
Now sending: OP 16 BRD, FC 0., NB 36.
From 0-0 to 0-0
Pkt # 0, ack # 40
Data: "······························load"
Sending...
Have packets: 0
More packets: 0
Now sending: OP 16 BRD, FC 0., NB 36.
From 0-0 to 0-0
Pkt # 0, ack # 40
Data: "······························load"
Sending...
Have packets: 0
More packets: 0
Now sending: OP 16 BRD, FC 0., NB 36.
From 0-0 to 0-0
Pkt # 0, ack # 40
Data: "······························load"
Sending...
Have packets: 0
Timed out
Closing and reopening channels
>
So I get the same results on all of pdp10-ka, pdp10-kl, and pdp10-ks. What is the output supposed to look like?
I just logged in on EXA and compiled SYSEN3;CHATST to .temp., and when I run it saying BRD LOAD (in uppercase!) I get responses. Try it (it also works with :CHATST, running SYS2;TS CHATST).
It turns out ITS assumes contact names in incoming RFC and BRD packets are in uppercase, but it doesn't make them uppercase if they aren't. So you need to write it in uppercase. Of course CHATST should make them uppercase.
Before merging the final version (maybe the current version!), let's rearrange things a bit. Maybe squash all into a single commit, or maybe make it one for ITS and another for the tools?
You know how you want it and how to make it be so, so go ahead? Now that I have a PDP10-KA, I might make NAMDRG use broadcast, but probably not until next week.
It turns out ITS assumes contact names in incoming RFC and BRD packets are in uppercase, but it doesn't make them uppercase if they aren't. So you need to write it in uppercase. Of course CHATST should make them uppercase.
Well, that makes a difference. Now I responses on EXA, EXS, and EXL. I haven’t updated KLH10 yet for ES and EX, so I don’t expect good responses there.
I updated KLH10 with your latest changes, and now EX, also, returns good data on a CHATST with "b LOAD". I'll update ES next.
Now NAMDRG uses broadcast, too. (And shows the whole location of free lispm instead of stopping at the first space.)
Right, these were merged in quick succession so I figured it would not cause a problem to anyone if the version wasn't bumped again.