<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>At least in terms of control data flow, on the 20, everything
goes through the JFN interface, which means you don't have much
re-coding to do in terms of reading and writing. This contrasts
with the brain damaged Unix socket model, which also exists on
Tops-20 as the BBN JCN interface. Most JSYi do the expected
thing, like <font size="4"><tt>SIBE%</tt></font>, for example.
There are some <font size="4"><tt>MTOPR%</tt></font> details that
are different, but these are easily special cased.</p>
<p><b><font size="4"><tt>SMTP</tt></font></b>:<br>
</p>
<ol>
<li>The bulk of the code in <font size="4"><tt>MMAILR</tt></font>
needs no change as it is reading and writing from <font
size="4"><tt>.PRIOU</tt></font> with no idea that there is no
terminal on the other side.</li>
<li>The DNS interface (<font size="4"><tt>HSTNAM</tt></font>)
worked, but was enhanced to use DECnet host numbers like the
other transports use (even though the number can't be used for
much)</li>
<li>This required an enhancement to the monitor to return them, <font
size="4"><tt>.NDVFX</tt></font> (an extension of <font
size="4"><tt>.NDVFY</tt></font>)<br>
</li>
</ol>
<div class="moz-cite-prefix"><b>TELNET</b>:</div>
<div class="moz-cite-prefix">
<ol>
<li>Handles DECnet</li>
<li>Special case code handles connection set up and error
handling, but this has gotten spaghettified.</li>
</ol>
<p><b>FTP</b></p>
<ol>
<li>Handles Internet, Chaos, PUP and I think something else</li>
<li>Very well architected and extensible to DECnet</li>
</ol>
<p><b>EFTPSER</b></p>
<ol>
<li>Designed for any transport and includes IP6 verbs which
certain client use, even over IP4. The Apple client uses them
whether or not you are doing IP6.<br>
</li>
<li>Requires a monitor modification to be placed in a top-level
fork so it can execute a <font size="4"><tt>LOGIN%</tt></font>
as per the <font size="4"><tt>USER</tt></font> and <font
size="4"><tt>PASS</tt></font> verbs.<br>
</li>
</ol>
</div>
<div class="moz-cite-prefix">The only place where I have bumped into
a potential difference is in the creation of port numbers or names
for data transfer. The following verbs exist:</div>
<div class="moz-cite-prefix">
<ol>
<li> <font size="4"><tt>PASV</tt></font>,request passive mode
and port, IP4<br>
</li>
<li><font size="4"><tt>PORT</tt></font>, explicitly designate
port for active use, this transfer, IP4<br>
</li>
<li><font size="4"><tt>EPRT</tt></font>, same as 1, IP6 (see
Apple, above)<br>
</li>
<li><font size="4"><tt>EPSV</tt></font>, same as 2, IP6 (Ditto)<br>
</li>
<li><font size="4"><tt>LPRT</tt></font>,same as 1, "long"</li>
<li><font size="4"><tt>LPSV</tt></font>, same as 2, "long"</li>
<li><font size="4"><tt>SPSV</tt></font>, same as 2, 'simplified'
(no RFC, a simple proposal)<br>
</li>
</ol>
<p>The data port has to be generated to not conflict with others
in use and that is a bit of a hack to do this: a random
selection is made from a range of ports based on job number. It
seems to me that two additional verbs would be appropriate:</p>
<ol>
<li><font size="4"><tt><b>D</b>PSV</tt></font>, same as 1,
above, DECnet</li>
<li><font size="4"><tt><b>D</b>PRT</tt></font>, same as 2,
above, DECnet<br>
</li>
</ol>
</div>
<div class="moz-cite-prefix">
<p>The reason for this is that I wouldn't use numbers, but rather
a six character random task name, like <font size="4"><tt>TASK-ZYAE1Q</tt></font>.
I believe there would be far less chance of clash this way.</p>
</div>
<div class="moz-cite-prefix">
<p>Again, the real hang up is the monitor modification for
EFTPSER.</p>
</div>
<div class="moz-cite-prefix">
<p>You can get yourself into trouble going from DECnet to
something else if you happen to find yourself on a 36 bit host
and are using 36 bit transfers, which the Tops-10/20
implementation supports, but IP does not (the ARPAnet apparently
did). The only program I am aware of that does this is <font
size="4"><tt>VIKING</tt></font>, a Columbia locally developed
pseudo-<font size="4"><tt>rsynch</tt></font> solution. I use it
between my 20's to take daily backups of development.<br>
</p>
</div>
<div class="moz-cite-prefix">The FTP client and server use eight bit
transfers, like DAP.<br>
</div>
<blockquote type="cite"
cite="mid:934E929E-AD5A-40A3-A2D4-744FC583F094@comcast.net">
<hr width="100%" size="2">
<pre class="moz-quote-pre" wrap="">On 11/8/21 9:27 AM, Paul Koning wrote:
</pre>
<pre class="moz-quote-pre" wrap="">I've thought about http over DECnet. That would be really easy. The obvious way to deal with any TCP-based protocol is just to send the byte streams over DECnet messages, in the same fashion as DECnet/Ultrix streaming mode DECnet sockets do. (Precisely how that works I don't remember.) In the case of HTTP, a natural simplification would be to send the entire header, in both directions, as a single message, with any data following in one or more additional messages.
The DECnet object number for HTTP should be 80, obviously. :-)
paul
<blockquote type="cite"><hr width="100%" size="2"><pre class="moz-quote-pre" wrap="">On Nov 7, 2021, at 9:54 PM, Peter Lothberg <a class="moz-txt-link-rfc2396E" href="mailto:roll@stupi.com"><roll@stupi.com></a> wrote:
In the "old days" we did SMTP over DECnet, has anyone considered doing Telnet, FTP, HTTP etc over
DECnet transport?
</pre></blockquote></pre>
</blockquote>
</body>
</html>