Implement Chaosnet broadcast sending

[bictorv]

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.

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. Additionally, NAMDRG uses broadcast to find lispm users and free lisp machines (see #2195 ).

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:

• implement broadcast TIME checking
• teach NAME to show free lisp machines
• teach NAME to broadcast using the LOAD protocol, and for responses with Users: n for n>0, connect with the NAME protocol 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.)

[larsbrinkhoff]

You added two more strings, but only increased the number by one. Is that right?

[eswenson1]

Seems he deleted one and added two to me, for a net gain of 1.

[bictorv]

Previously the state %CSFRN (foreign protocol mode) would be presented as "LOWLVL" which seems arachaic (FORIGN is clearer, in my mind), while anything over %CSFRN was presented as "GARBAG". With the new code, %CSBRS (which is %CSFRN+1) is "BRDSNT" and anything higher is "GARBAG".

[larsbrinkhoff]

Oh, right! Never mind then.

[larsbrinkhoff]

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?

[bictorv]

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").

[bictorv]

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.

[bictorv]

Now NAMDRG uses broadcast, too. (And shows the whole location of free lispm instead of stopping at the first space.)

[larsbrinkhoff]

Bumped NAMDRG version.

[eswenson1]

I noticed, @larsbrinkhoff, that you didn’t bump the version of SYSTEM;CHAOS. Is that because we did in the other PR? Ideally FN2 should increment after every PR, in my mind.

[larsbrinkhoff]

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.

[eswenson1]

Ok.