The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
* [TUHS] Unix V8 Chaosnet, any takers?
@ 2022-07-14 11:08 Lars Brinkhoff
  2022-07-14 16:37 ` [TUHS] " John Floren
  0 siblings, 1 reply; 23+ messages in thread
From: Lars Brinkhoff @ 2022-07-14 11:08 UTC (permalink / raw)
  To: tuhs

Hello,

Unix V8 has some code for Chaosnet support.  There is a small hobbyist
Chaos network going with Lispm, PDP-10, PDP-11, and Berkeley Unix nodes.
Is there anyone who would be interested in trying to see if the V8 code
is in a workable state, and get it running?

Best regards,
Lars Brinkhoff

^ permalink raw reply	[flat|nested] 23+ messages in thread
* [TUHS] Re: Unix V8 Chaosnet, any takers?
@ 2022-07-15  8:51 Paul Ruizendaal via TUHS
  0 siblings, 0 replies; 23+ messages in thread
From: Paul Ruizendaal via TUHS @ 2022-07-15  8:51 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

> Message: 6
> Date: Thu, 14 Jul 2022 17:51:39 +0000
> From: segaloco <segaloco@protonmail.com>
> 
> Given V8 being rebased on 4(.1?)BSD, I suspect the path of least resistance would be to just start grafting V8 code onto the working 4.1BSD.

I doubt that V8 is "rebased on 4(.1?)BSD": in my understanding it ported some code from 4xBSD, but it is a different code base.

As I currently understand it, the V8 kernel:

- is a further development from 32V
- retains the code organisation of the V5..32V versions
- adds virtual memory code from BSD
- adds select() from BSD

and then adds all the V8 innovation on top of that (streams, file system switch, virtual proc file system, networking, remote file system, support for the Blit terminal, etc.)

In particular in the area of networking the V8 kernel is organised quite differently from the 4xBSD kernel, including the Chaosnet driver (i.e. it is streams based).

Paul


^ permalink raw reply	[flat|nested] 23+ messages in thread
* [TUHS] Re: Unix V8 Chaosnet, any takers?
@ 2022-07-15 10:25 Noel Chiappa
  2022-07-15 11:53 ` Theodore Ts'o
  2022-07-16  6:59 ` Lars Brinkhoff
  0 siblings, 2 replies; 23+ messages in thread
From: Noel Chiappa @ 2022-07-15 10:25 UTC (permalink / raw)
  To: tuhs; +Cc: jnc

    > From: Lars Brinkhoff

    > There is a small hobbyist Chaos network going

What encapsulation are they using to transmit CHAOS packets (over the
Internet, I assume)? I know there was an IP protocol number assigned for
CHAOS (16.), but I don't recall if there was ever a spec? (Which is kind of
amusing, since in 'Assigned Numbers', the person responsible for 16. is ....
me! :-)

There was a spec for encapsulating IP in CHAOS, and that actually _was_
implemented at MIT BITD; it was used for a while to get IP traffic to a Unix
machine (V7, IIRC) over on main campus, at a stage when only CHAOS hardware
(very confusing that the same name was applied to hardware, and a protocol
suite) ran across to main campus from Tech Square.


    > From: Grant Taylor

    > I wonder if there is an opportunity for something that pretends to be
    > the remote side locally, sends the data via some other
    > non-latency-sensitive protocol to a counter part where the counter part
    > pretends to be the near side.

Let's think through the details. The near-end 'invisibility box' (let's call
it) is going to have to send acks to the original source machine, otherwise
that will time out, abort the connection, etc. The originating machine is its
own thing, and this behaviour can't be controlled/stopped.

(This, BTW, shows a key difference between 'local' and 'across network'
modes, a recent topic here; in a situation where two distinct machines are
cooperating across a network, the other machine is its own entity, and can't
be expected/guaranteed to do anything in particular at all.)

In addition, the near-end invisibility box is going to have to keep a copy of
each packet, until the destination machine sends an ack to the invisibility
box - because if the packet is lost, the invisibility box is going to have to
retransmit it. (The original source is not going to - it's already gotten an
ack, so as far as it's concerned, that packet is done and dusted.) And the
near-end invisibility box is also going to have to have to have a time-out
timer, so that when the ack isn't seen, it will know to retransmit the packet.

There's no point to _also_ sending the acks on to the originating machine;
they won't do anything useful, and might just confuse it.

So, let's see now: the near-end invisibility box buffers the packet, looks
for an ack, times out when it doesn't see it, re-transmits the packet - that
sounds familiar? Oh, right, it's a reliable connection.

And presumably there's an invisibility box at the far end too, so the same
can happen for any data packets the destination machine sends.

The only question is whether, when doing the detailed design, there's any
point to having the destination machine's acks sent to the near-end
invisibility box - or just use them at the far-end invisibility box. (I.e.
create three reliable connections: i) a CHAOS connection originating
machine<->near-end invisibility box; ii) {whatever} near-end invisibility
ox<->far-end invisibility box; iii) CHAOS far-end invisibility box<->original
destination machine - and glue them together.)

That is in some sense simpler than creating an extra-ordinary mechanism to
have a 'helper' box in the middle of the connection (to terminate the CHAOS
connection from the original machine, and have another CHAOS connection, but
with an enhanced time-out mechanism which can cope with larger RTT's, from
there to the original destination); and the same in the other direction.


The amusing thing is that the CHAOS protocol stack actually already had
something very similar to this, BITD. If one were sitting at a machine that
only had CHAOS, and one wanted to (say) TELNET to an ARPANET host, there was
a CHAOS service which ARPANET hosts on the CHAOSNET provided: open a CHAOS
connection to that serrver, and it would open an NCP connection to one's
intended ultimate destination, and glue the byte streams together. (The
ultimate destination was passed as data over the CHAOS connection, when
opening it.)

	Noel

^ permalink raw reply	[flat|nested] 23+ messages in thread
* [TUHS] Re: Unix V8 Chaosnet, any takers?
@ 2022-07-16 15:51 Noel Chiappa
  2022-07-16 17:02 ` Warner Losh
  0 siblings, 1 reply; 23+ messages in thread
From: Noel Chiappa @ 2022-07-16 15:51 UTC (permalink / raw)
  To: tuhs; +Cc: jnc

    > From: Warner Losh

    > V7 could mean a modification of net unix

What's "net unix" anyway? I know of the Net releases from CSRG, but this
much precedes that.

What did people with PDP-11 V7 who wanted TCP/IP do, anyway?

	Noel

^ permalink raw reply	[flat|nested] 23+ messages in thread
* [TUHS] Re: Unix V8 Chaosnet, any takers?
@ 2022-07-16 20:02 Paul Ruizendaal
  0 siblings, 0 replies; 23+ messages in thread
From: Paul Ruizendaal @ 2022-07-16 20:02 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

Apologies for being off-topic

> What did people with PDP-11 V7 who wanted TCP/IP do, anyway?

Taking it slightly broader (PDP-11 instead of V7), there is a lot of discussion about that on Mike Meuss’ TCP-digest mailing list:

https://ftp.ripe.net/rfc/museum/tcp-ip-digest/

There is a 1985 index of available implementations as well ( https://ftp.ripe.net/rfc/museum/tcp-ip-implementations.txt.1 ). It includes the following options for PDP-11 systems:


1.7.5. UNIX 2.9BSD

DESCRIPTION:

       2.9BSD TCP/IP is an adaptation  of  Berkeley's  original  VAX
    TCP/IP  (running  under  BSD  4.1B  UNIX)  which  in  turn is an
    offshoot of BBN's VAX TCP/IP.  2.9BSD TCP/IP runs on  PDP-11/44s
    and  PDP-11/70s.    The 2.8 version from SRI was adapted by Bill
    Croft (formerly at SRI), then  Tektronix  adapted  it  for  2.9.
    Berkeley  took  over modification of the software and brought it
    back to SRI where Dan Chernikoff and Greg Satz adapted it for  a
    later  release  of 2.9.  In addition to TCP/IP, UDP, ARP and the
    raw packet  interface  is  available.  ICMP  redirects  are  not
    supported.    User  software  implementations include Telnet and
    FTP, plus Berkeley-developed local  net  protocols,  RWHO,  RSH,
    RLOGIN, and RCP.

       2.9BSD  with  TCP/IP support could probably be made to run on
    smaller PDP-11s although the address space would be  very  tight
    and might present problems.


1.7.6. Venix/11 TCP/IP

DESCRIPTION:

       This  is  based  on  the "PDP-11/45" implementation available
    from the MIT Laboratory for  Computer  Science.    It  has  been
    ported  to  a V7 UNIX system, in particular VenturCom's Venix/11
    V2.0.

       As little of the processing as possible takes  place  in  the
    kernel,   to   minimize  the  code  space  required.    It  fits
    comfortably on I&D machines,  but  is  almost  hopeless  on  the
    smaller  machines.   The kernel includes a proNET device driver,
    IP fragment reassembly, IP header processing,  local-net  header
    processing,  and simple routing.  The rest of the IP processing,
    and all of the UDP and TCP functions,  are  in  user  libraries.
    The psuedo-teletype driver is also in the kernel, and is used by
    Server TELNET.

       User programs handle ICMP processing; User and Server TELNET,
    SMTP,  TFTP,  Finger,  and Discard.  There are User programs for
    Nicname and Hostname.   IEN-116  nameservers  are  used  by  all
    programs,  and  an IEN-116 nameserver is also provided.  The TCP
    used is very simple, not very fast, and lies about windows.   No
    FTP is available, nor is one currently planned.


1.7.8. BBN-V6-UNIX

DESCRIPTION:

       This  TCP/IP/ICMP  implementation  runs  as a user process in
    version 6 UNIX, with modifications obtained from BBN for network
    access.  IP  reassembles  fragments  into  datagrams, but has no
    separate IP user  interface.    TCP  supports  user  and  server
    Telnet,  echo,  discard,  internet  SMTP  mail,  and  FTP.  ICMP
    generates replies to Echo Requests, and sends Source-Quench when
    reassembly buffers are full.

       1. Hardware  -  PDP-11/70 and PDP-11/45 running UNIX version
          6, with BBN IPC additions.

       2. Software - written in C, requiring 25K instruction space,
          20K  data  space.    Supports  10  connections (including
          "listeners").

       3. Unimplemented protocol features:

             - TCP - Discards out-of-order segments.

             - IP - Does not handle some options and ICMP messages.


1.7.9. v 3COM-UNET

DESCRIPTION:

       UNET is a communication software package which  enables  UNIX
    systems  to  communicate  using  TCP/IP  protocols.    UNET will
    utilize any physical communications media, from low speed  links
    such as twisted pair RS-232C to high speed coaxial links such as
    Ethernet.  All layers of the UNET package are directly available
    to   the  user.    The  highest  layer  provides  user  programs
    implementing  ARPA  standard  File  Transfer  Protocol   (UFTP),
    Virtual  Terminal  Protocol  (UVTP), and Mail Transfer Protocols
    (UMTP).  These programs in  turn  utilize  the  virtual  circuit
    services  of the TCP.  The TCP protocol is implemented on top of
    the IP.  Finally, IP can simultaneously  interface  to  multiple
    local  networks.    UNET  implements  5  of  the 7 layers of the
    International    Standards     Organization     Open     Systems
    Interconnection  Reference  Model,  layers  2  through  6: Link,
    Network, Transport, Session, and Presentation.  Features of  TCP
    6   not   yet   implemented   are   Precedence   and   Security,
    End-of-Letter, and Urgent.  Feature of IP 4 not yet  implemented
    is Options.


Of these, we have 2.9BSD and (a forerunner of) BBN-V6-Unix available on the TUHS Unix Tree. The Venix/11 source and the 3COM source appear lost. These (unfortunately) are the ones that were implemented on top of V7.

Also, BBN back-ported the TCP/IP code of BBN VAX-TCP to V7 for their C/70 Unix.







^ permalink raw reply	[flat|nested] 23+ messages in thread
* [TUHS] Re: Unix V8 Chaosnet, any takers?
@ 2022-07-17 23:39 Noel Chiappa
  2022-07-18  1:01 ` Ron Natalie
  0 siblings, 1 reply; 23+ messages in thread
From: Noel Chiappa @ 2022-07-17 23:39 UTC (permalink / raw)
  To: tuhs; +Cc: jnc

    > From: Warner Losh

    >> What's "net unix" anyway?

    >  I'm referring to the University of Illinois distribution

Ah, OK.

    > I have seen references to it in the ARPAnet census documents running on
    > both V6 and V7 (though mostly they were silent about which version).

Well, V7 came out in January, 1979, and NCP wasn't turned off until January,
1983, so people had a lot of time to get it running under V7.

    > I thought this was the normal nomenclature of the time, but I may be
    > mistaken.

I'm not sure what it was usually called; we didn't have much contact with it
at MIT (although I had the source; I'm the one that provided it to TUHS).

The problem was that although MIT had two IMPs, all the ports on them were
spoken for, for big time-sharing mainframes (4 PDP-10's running ITS; 1
running TWENEX; a Multics), so there were no ports available to plug in a
lowly PDP-11. (We were unable to get an IP gateway (router) onto the ARPANET
until MIT got some of the first C/30 IMPs.) So we had no use for the NCP Unix
(which I vaguely recall was described as 'the ARPANET Unix from UIll').

	Noel

^ permalink raw reply	[flat|nested] 23+ messages in thread
* [TUHS] Re: Unix V8 Chaosnet, any takers?
@ 2022-07-18 17:07 Noel Chiappa
  0 siblings, 0 replies; 23+ messages in thread
From: Noel Chiappa @ 2022-07-18 17:07 UTC (permalink / raw)
  To: tuhs; +Cc: jnc

    > From: Ron Natalie

    > We had NCP running on the JHU kernel

Which NCP implementation was that, the one from UIUC, or something else? (I'm
curious about the one that someone here - I forget who - mentioned, where
IIRC they thought it was a new one, not the UIUC one. I'm a little boggled
that with so little use for one - there weren't many NCP sites - someone
would have gone to all the work to do another one. But it's possible...)


If you all used the UIUC one, what did you call it? I looked through the email
about releases from NOSC (who seemed to be the focal point for maintaining
it at one point):

  https://minnie.tuhs.org/cgi-bin/utree.pl?file=SRI-NOSC/new/dist.log

but it doesn't give a name for it. The documentation:

  https://minnie.tuhs.org/cgi-bin/utree.pl?file=SRI-NOSC/doc/IllinoisNCP.nr

doesn't either (other than 'Illinois NCP').


It does seem that they were semi-using V7; see e.g.:

  https://minnie.tuhs.org/cgi-bin/utree.pl?file=SRI-NOSC/green/c.c

but the code looks very V6-ish; see e.g.:

  https://minnie.tuhs.org/cgi-bin/utree.pl?file=SRI-NOSC/ken/text.c


	Noel

^ permalink raw reply	[flat|nested] 23+ messages in thread

end of thread, other threads:[~2022-07-18 17:07 UTC | newest]

Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-07-14 11:08 [TUHS] Unix V8 Chaosnet, any takers? Lars Brinkhoff
2022-07-14 16:37 ` [TUHS] " John Floren
2022-07-14 17:00   ` Lars Brinkhoff
2022-07-14 17:51     ` segaloco via TUHS
2022-07-14 18:19       ` Ron Natalie
2022-07-14 20:32         ` Tom Teixeira
2022-07-14 20:39           ` Ron Natalie
2022-07-15  0:33             ` Grant Taylor via TUHS
2022-07-15  4:29               ` Erik E. Fair
2022-07-14 19:36       ` Lars Brinkhoff
2022-07-14 21:50         ` segaloco via TUHS
2022-07-16  6:38           ` Lars Brinkhoff
2022-07-16 14:05             ` Warner Losh
2022-07-15  8:51 Paul Ruizendaal via TUHS
2022-07-15 10:25 Noel Chiappa
2022-07-15 11:53 ` Theodore Ts'o
2022-07-16  6:59 ` Lars Brinkhoff
2022-07-16 15:51 Noel Chiappa
2022-07-16 17:02 ` Warner Losh
2022-07-16 20:02 Paul Ruizendaal
2022-07-17 23:39 Noel Chiappa
2022-07-18  1:01 ` Ron Natalie
2022-07-18 17:07 Noel Chiappa

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).