How the Arpanet Protocols Worked (2021)(twobithistory.org)
twobithistory.org
How the Arpanet Protocols Worked (2021)
https://twobithistory.org/2021/03/08/arpanet-protocols.html
5 comments
> parallel hardware interface
The physical layer as described in report 1822 is bit-serial, but uses synchronous clocking scheme without fixed baud-rate reminiscent of parallel SCSI's REQ/ACK. It is a weird scheme for serial links, but it has the clear advantage that it adapts to cable length automatically (but runs at significantly smaller bitrate that could be supported by the cable, which probably was not exactly an issue in 70's).
In fact the whole report 1822 deals mostly in bits (the messages on the IMP-host interface can have arbitrary bit lengths). Obviously this was done in order to support architectures with weird word sizes (eg. 36bit PDP-10).
The physical layer as described in report 1822 is bit-serial, but uses synchronous clocking scheme without fixed baud-rate reminiscent of parallel SCSI's REQ/ACK. It is a weird scheme for serial links, but it has the clear advantage that it adapts to cable length automatically (but runs at significantly smaller bitrate that could be supported by the cable, which probably was not exactly an issue in 70's).
In fact the whole report 1822 deals mostly in bits (the messages on the IMP-host interface can have arbitrary bit lengths). Obviously this was done in order to support architectures with weird word sizes (eg. 36bit PDP-10).
There are several boxes in the chain. PDP-11 to IMP adapter connection was a ribbon cable, and IMP adapter to IMP was bit-serial but multi-conductor.
Everything required a lot of boxes back then. An IMP adapter was about 4U of rack space.
Everything required a lot of boxes back then. An IMP adapter was about 4U of rack space.
Bit-serial but multi-conductor cable. The 6 pairs, ground and if I count correctly two single-ended status lines make more sense than 30-pair Cisco serial cables or 34-pair HSSI of the 90's…
You mean with luxurious word sizes! ;)
Well, this cleared up the NCP confusion for me at least. I was only vaguely aware of how the Arpanet functioned, but I had also seen this "NCP was a precursor to TCP" claim, every time Arpanet came up in discussions. But it wasn't that at all. Program, not Protocol.
ARPANET TIPs had an obscure but documented low level feature that you could send commands on behalf of other users connected to the same TIP, configuring their terminal settings, disconnecting and reconnecting their sessions to other hosts and ports! You could also execute annoying commands like "@S B" (Send Break) that inserted an ^G into their input stream on ITS, or "@I 33" (Intercept 33 octal) that changed their TIP command intercept character from @ to ESC.
Ostensibly it was so you could configure and control a Teletype or line printer connected directly to a TIP without a modem, but you could also set up TIP-to-TIP links for chatting with other users on different TIPs by bouncing packets directly off a socket without actually logging in to any host!
MIT AI Lab Tourist Policy (why jslabovitz and I were able to get "tourist" accounts at the MIT AI Lab just by asking -- or actually just trying to log in as an unknown user, and automatically being offered our own account!):
https://donhopkins.medium.com/mit-ai-lab-tourist-policy-f73b...
https://news.ycombinator.com/item?id=13518273
jslabovitz on Jan 30, 2017 | parent | context | favorite | on: PDP-10/its: Incompatible Timesharing System
Around 1982, I had an account on MIT-MC, an ITS computer. I was not an MIT student -- rather, a curious teenage hacker from DC. I'd found a text file with 'interesting modem numbers,' and one of those was to a DoD TAC (basically, a dial-in). I recall the text file had a note saying how to connect (via NCP, not TCP/IP) to MIT-MC.
I connected, and remember playing around (as we did) at the login prompt. I probably tried to login as 'guest' or something, and the result was basically, 'There's no user by that name. Do you want an account?' Of course, I said yes -- and shortly received my own account.
Stallman may have been sponsoring logins for folks like myself; he definitely was a little later when I got an account on MIT-AI (or was it MIT-OZ?), which was by that point a TOPS-20 machine.
ITS was a very bizarre system, really with its own social culture. Even in 1982, it felt strangely archaic. The debugger-as-shell was definitely an interesting concept.
Once I accidentally deleted a file. I felt awful, and emailed one of the admins, assuming they'd kick me off. He was like, 'Ah, no worries. We'll just restore it from tape.'
DonHopkins on Jan 30, 2017 | next [–]
NBS TIP: 301-948-3850
I dialed it enough times that I still remember it. Much thanks to Bruce of "Bruce's NorthStar" BBS in Virginia for that phone number. [1]
MIT-MC: @L 236
MIT-AI: @L 134
MIT-DM: @L 70
MIT-ML: @L 198
Anyone remember how to do a TIP-to-TIP link, as documented on page 5-4 of the "Users Guide to the Terminal IMP" [2], by connecting an input and output socket of one TIP to an input and output socket of another TIP, through an unsuspecting host, so you could chat back and forth directly between two TIP dial-ups, without actually logging into the host?
It went something like @HOST #, @SEND TO SOCKET #, @RECEIVE FROM SOCKET #, @PROTOCOL BOTH, making sure the sockets were different parity so as not to violate the Anita Bryant clause with homosocketuality. [3]
You could also add the octal device port number of any other TIP user on your same TIP after the @ and before the command, to execute those commands on their session. (See page 5-7, "Setting Another Terminal's Parameters".) BBN wrote such great documentation and would mail copies of it for free to anyone who asked (that's how I got mine), you couldn't even call it security by obscurity!
The "ARPANET" episode of "The Americans" really missed the boat about how easy it was to break into the ARPANET. I didn't even have to kill anyone! [3] [4] Makes me wonder about the part about squeezing your anus... [5]
What was your uname?
-A2DEH
[1] https://games.slashdot.org/comments.pl?sid=242967&cid=196819...
[2] https://archive.org/details/bitsavers_bbntipADA0eTerminalIMP...
[3] https://news.ycombinator.com/item?id=12422813
[4] https://en.wikipedia.org/wiki/Arpanet_(The_Americans)
[5] https://www.youtube.com/watch?v=hVth6T3gMa0
[6] https://www.youtube.com/watch?v=s3OMSMq9zPA
Ostensibly it was so you could configure and control a Teletype or line printer connected directly to a TIP without a modem, but you could also set up TIP-to-TIP links for chatting with other users on different TIPs by bouncing packets directly off a socket without actually logging in to any host!
MIT AI Lab Tourist Policy (why jslabovitz and I were able to get "tourist" accounts at the MIT AI Lab just by asking -- or actually just trying to log in as an unknown user, and automatically being offered our own account!):
https://donhopkins.medium.com/mit-ai-lab-tourist-policy-f73b...
https://news.ycombinator.com/item?id=13518273
jslabovitz on Jan 30, 2017 | parent | context | favorite | on: PDP-10/its: Incompatible Timesharing System
Around 1982, I had an account on MIT-MC, an ITS computer. I was not an MIT student -- rather, a curious teenage hacker from DC. I'd found a text file with 'interesting modem numbers,' and one of those was to a DoD TAC (basically, a dial-in). I recall the text file had a note saying how to connect (via NCP, not TCP/IP) to MIT-MC.
I connected, and remember playing around (as we did) at the login prompt. I probably tried to login as 'guest' or something, and the result was basically, 'There's no user by that name. Do you want an account?' Of course, I said yes -- and shortly received my own account.
Stallman may have been sponsoring logins for folks like myself; he definitely was a little later when I got an account on MIT-AI (or was it MIT-OZ?), which was by that point a TOPS-20 machine.
ITS was a very bizarre system, really with its own social culture. Even in 1982, it felt strangely archaic. The debugger-as-shell was definitely an interesting concept.
Once I accidentally deleted a file. I felt awful, and emailed one of the admins, assuming they'd kick me off. He was like, 'Ah, no worries. We'll just restore it from tape.'
DonHopkins on Jan 30, 2017 | next [–]
NBS TIP: 301-948-3850
I dialed it enough times that I still remember it. Much thanks to Bruce of "Bruce's NorthStar" BBS in Virginia for that phone number. [1]
MIT-MC: @L 236
MIT-AI: @L 134
MIT-DM: @L 70
MIT-ML: @L 198
Anyone remember how to do a TIP-to-TIP link, as documented on page 5-4 of the "Users Guide to the Terminal IMP" [2], by connecting an input and output socket of one TIP to an input and output socket of another TIP, through an unsuspecting host, so you could chat back and forth directly between two TIP dial-ups, without actually logging into the host?
It went something like @HOST #, @SEND TO SOCKET #, @RECEIVE FROM SOCKET #, @PROTOCOL BOTH, making sure the sockets were different parity so as not to violate the Anita Bryant clause with homosocketuality. [3]
You could also add the octal device port number of any other TIP user on your same TIP after the @ and before the command, to execute those commands on their session. (See page 5-7, "Setting Another Terminal's Parameters".) BBN wrote such great documentation and would mail copies of it for free to anyone who asked (that's how I got mine), you couldn't even call it security by obscurity!
The "ARPANET" episode of "The Americans" really missed the boat about how easy it was to break into the ARPANET. I didn't even have to kill anyone! [3] [4] Makes me wonder about the part about squeezing your anus... [5]
What was your uname?
-A2DEH
[1] https://games.slashdot.org/comments.pl?sid=242967&cid=196819...
[2] https://archive.org/details/bitsavers_bbntipADA0eTerminalIMP...
[3] https://news.ycombinator.com/item?id=12422813
[4] https://en.wikipedia.org/wiki/Arpanet_(The_Americans)
[5] https://www.youtube.com/watch?v=hVth6T3gMa0
[6] https://www.youtube.com/watch?v=s3OMSMq9zPA
>Read sockets were even-numbered while write sockets were odd-numbered; whether a socket was a read socket or a write socket was referred to as the socket’s gender. There were no “port numbers” like in TCP.
https://news.ycombinator.com/item?id=14178993
DonHopkins on April 23, 2017 | prev | next [–]
Back in the "bad old days" of the simplex NCP protocol [1], before the full duplex TCP/IP protocol legalized same-sex network connections, connect and listen sockets had gender defined by their parity, and all connections were required to use sockets with different parity gender (one even and the other odd -- I can't remember which was which, or if it even mattered -- they just had to be different).
The act of trying to connect an even socket to another even socket, or an odd socket to another odd socket, was considered a "peculiar error" called "homosocketuality", which was strictly forbidden by internet protocols, and mandatory "heterosocketuality" was called the "Anita Bryant feature" [2].
http://www.saildart.org/IMPSER.DOC[SS,SYS]
When the error code is zero, the next 8 bit byte is the Stanford peculiar error code, followed by 72 bits of the ailing command returned. Here are the Stanford error codes. [...]
IGN 3 Illegal Gender (Anita Bryant feature--sockets must be heterosocketual, ie. odd to even and even to odd) [...]
Illegal gender in RFC, host hhh/iii, link 0
The host is trying to engage us in homosocketuality. Since this is against the laws of God and ARPA, we naturally refuse to consent to it.
http://www.saildart.org/FTP.NCP[S,NET]
[1] https://en.wikipedia.org/wiki/Network_Control_Protocol_(ARPA...
[2] https://www.youtube.com/watch?v=5tHGmSh7f-0
https://news.ycombinator.com/item?id=14178993
DonHopkins on April 23, 2017 | prev | next [–]
Back in the "bad old days" of the simplex NCP protocol [1], before the full duplex TCP/IP protocol legalized same-sex network connections, connect and listen sockets had gender defined by their parity, and all connections were required to use sockets with different parity gender (one even and the other odd -- I can't remember which was which, or if it even mattered -- they just had to be different).
The act of trying to connect an even socket to another even socket, or an odd socket to another odd socket, was considered a "peculiar error" called "homosocketuality", which was strictly forbidden by internet protocols, and mandatory "heterosocketuality" was called the "Anita Bryant feature" [2].
http://www.saildart.org/IMPSER.DOC[SS,SYS]
When the error code is zero, the next 8 bit byte is the Stanford peculiar error code, followed by 72 bits of the ailing command returned. Here are the Stanford error codes. [...]
IGN 3 Illegal Gender (Anita Bryant feature--sockets must be heterosocketual, ie. odd to even and even to odd) [...]
Illegal gender in RFC, host hhh/iii, link 0
The host is trying to engage us in homosocketuality. Since this is against the laws of God and ARPA, we naturally refuse to consent to it.
http://www.saildart.org/FTP.NCP[S,NET]
; Try to initiate connection
loginj:
init log,17
sixbit /IMP/
0
jrst noinit
setzm conecb
setom conecb+lsloc
move ac3,hostno
movem ac3,conecb+hloc
setom conecb+wfloc
movei ac3,40
movem ac3,conecb+bsloc
move ac3,consck
trnn ac3,1
jrst gayskt ; only heterosocketuals can win!
movem ac3,conecb+fsloc
mtape log,[
=15
byte (6) 2,24,0,7,7
] ; Time out CLS, RFNM, RFC, and INPut
[...]
gayskt: outstr [asciz/Homosocketuality is prohibited (the Anita Bryant feature)
/]
ife rsexec,<jrst rstart;>exit 1,
[1] https://en.wikipedia.org/wiki/Network_Control_Protocol_(ARPA...
[2] https://www.youtube.com/watch?v=5tHGmSh7f-0
Maybe you could add (2021) at the end of the title
First off, the IMP to host interface was a parallel hardware interface. Each type of computer attached to an IMP had to have a custom-designed interface unit that connected to the computer's own I/O system. The effect was that the IMP appeared to each host computer as a reliable I/O device. Here's the description of the interface unit for the DEC PDP-11.[1]
There were several models of IMPs. There was even a distributed, redundant IMP, called PLURIBUS. That was a strange machine built out of 16 Lockheed SUE minicomputers, with partially shared memory. BBN put that together. That was the beginning of network switches bigger than one CPU, but that idea was not used again until the era of big Internet routers about 15 years later.
Links between IMPs had both reliability and flow control. No packet was sent until a receiving buffer was available. So no packets were dropped due to congestion. Not at the link level, and not at the end to end level.
Congestion problems manifested themselves as the network stalling. This was a problem in the early days, but was gradually fixed. There was a fragmentation and reassembly system, which could result in overcommitting buffers. Once someone locked up the entire ARPANET in reassembly lockup by sending a pattern of messages that caused buffer fragmentation.
The obsession with buffer space came from the high cost of memory at the time. It was generally thought that congestion management was about not running out of buffer space. Now we know better. See "bufferbloat".
The IMP to IMP system was trusted within itself. So protocol bugs in the IMP to IMP protocol could cause multiple connections or multiple IMPs to fail.
One of the reasons that IP is unreliable is because that prevents trouble on one stream from messing up other streams. In exchange for less reliability per stream, you get better reliability for the whole system.
[1] http://www.bitsavers.org/pdf/dec/unibus/IMP11-B_Arpanet_Inte...