Difference between revisions of "Talk:Network Control Protocol"

From Computer History Wiki
Jump to: navigation, search
(How to ICP: RFC-165 doesn't do it?)
(How to ICP: That duality is because of the way the ICP works)
 
Line 7: Line 7:
  
 
For one thing, it seems like the "Logger" has a dual status as a TELNET server, ''and'' a part of ICP.  What's up with that?! [[User:Larsbrinkhoff|Larsbrinkhoff]] ([[User talk:Larsbrinkhoff|talk]]) 17:15, 20 December 2024 (CET)
 
For one thing, it seems like the "Logger" has a dual status as a TELNET server, ''and'' a part of ICP.  What's up with that?! [[User:Larsbrinkhoff|Larsbrinkhoff]] ([[User talk:Larsbrinkhoff|talk]]) 17:15, 20 December 2024 (CET)
 +
 +
: I suspect that's due to the weirdness of the NCP, and its ICP. That's basically because NCP HHP connections are unidirectional (in terms of data flow) - so a bi-directional connection (like what TCP gives you - I'm not sure NCP has a term for 'a bidirectional pair of HHP connections') actually involves two separate HHP connections. And remember that in NCP, the software on the host isn't really involved in data flow - it just sends packets to a specified 'socket' at the destination, and the IMP does all the work. Also, only a single distant socket can sed packets to a local socket at a time.
 +
: So, to get everything for a 'bi-directional connection' set up (chose the sockets at each end, and let the other end know what they are), the host ''does'' have to get involved; so the ICP 'protocol' has to be done in the host. So the server, on hearing from the user what socket they're going to use ('U'), ''it'' picks the local socket ''it'''s going to use ('S'), and sends that to the user; each can then set up the two unidirectional connections. RFC-165 does explain this all pretty well - once you get your mind wrapped around the fact that HHP connections are so very different from TCP connections.
 +
: Which explains why "the 'Logger' has a dual status as a TELNET server, ''and'' a part of ICP". The ICP is a whole separate protocol; so one could do two separate modules - one for the TELNET protocol, and one for the ICP - or one could combine them, as they have done.
 +
: Does this all make sense, now? If my explanation is clear, and correct, I'll add it to the article, because I don't think this is all explained there (yet). [[User:Jnc|Jnc]] ([[User talk:Jnc|talk]]) 19:36, 23 December 2024 (CET)

Latest revision as of 19:37, 23 December 2024

How to ICP

I find it infuriating how no single document clearly and unambiguously lays out the steps to do an ICP in terms of the Host-Host protocol. I'm about to test what the ITS NCP does, and I will be sure to document it here. Larsbrinkhoff (talk) 16:09, 20 December 2024 (CET)

RFC-165 doesn't do it? I have a hard-copy of the ARPANET Protocol Handbook, and RFC-165 is just about identical to NIC 7101 ("Official Initial Connection Protocol") from the APH. (Actually, I see a scan of the APH is available online now, here; NIC 7101 is on pp 91-95 of the scan, so you can see it's almost identical.
Now, NIC 7101 may not provide a clear and unambiguous description of the steps needed; I can't help you there! (If so, take it up with the ghost of Postel!) That's all the documentation we had! Jnc (talk) 17:29, 20 December 2024 (CET)

For one thing, it seems like the "Logger" has a dual status as a TELNET server, and a part of ICP. What's up with that?! Larsbrinkhoff (talk) 17:15, 20 December 2024 (CET)

I suspect that's due to the weirdness of the NCP, and its ICP. That's basically because NCP HHP connections are unidirectional (in terms of data flow) - so a bi-directional connection (like what TCP gives you - I'm not sure NCP has a term for 'a bidirectional pair of HHP connections') actually involves two separate HHP connections. And remember that in NCP, the software on the host isn't really involved in data flow - it just sends packets to a specified 'socket' at the destination, and the IMP does all the work. Also, only a single distant socket can sed packets to a local socket at a time.
So, to get everything for a 'bi-directional connection' set up (chose the sockets at each end, and let the other end know what they are), the host does have to get involved; so the ICP 'protocol' has to be done in the host. So the server, on hearing from the user what socket they're going to use ('U'), it picks the local socket it's going to use ('S'), and sends that to the user; each can then set up the two unidirectional connections. RFC-165 does explain this all pretty well - once you get your mind wrapped around the fact that HHP connections are so very different from TCP connections.
Which explains why "the 'Logger' has a dual status as a TELNET server, and a part of ICP". The ICP is a whole separate protocol; so one could do two separate modules - one for the TELNET protocol, and one for the ICP - or one could combine them, as they have done.
Does this all make sense, now? If my explanation is clear, and correct, I'll add it to the article, because I don't think this is all explained there (yet). Jnc (talk) 19:36, 23 December 2024 (CET)