[HECnet] "IP protocols on DECnet'

[Thomas DeBellis]

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 SIBE%, for example. 
There are some MTOPR% details that are different, but these are easily 
special cased.

*SMTP*:

 1. The bulk of the code in MMAILR needs no change as it is reading and
    writing from .PRIOU with no idea that there is no terminal on the
    other side.
 2. The DNS interface (HSTNAM) worked, but was enhanced to use DECnet
    host numbers like the other transports use (even though the number
    can't be used for much)
 3. This required an enhancement to the monitor to return them, .NDVFX
    (an extension of .NDVFY)

*TELNET*:

 1. Handles DECnet
 2. Special case code handles connection set up and error handling, but
    this has gotten spaghettified.

*FTP*

 1. Handles Internet, Chaos, PUP and I think something else
 2. Very well architected and extensible to DECnet

*EFTPSER*

 1. 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.
 2. Requires a monitor modification to be placed in a top-level fork so
    it can execute a LOGIN% as per the USER and PASS verbs.

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:

 1. PASV,request passive mode and port, IP4
 2. PORT, explicitly designate port for active use, this transfer, IP4
 3. EPRT, same as 1, IP6 (see Apple, above)
 4. EPSV, same as 2, IP6 (Ditto)
 5. LPRT,same as 1, "long"
 6. LPSV, same as 2, "long"
 7. SPSV, same as 2, 'simplified' (no RFC, a simple proposal)

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:

 1. *D*PSV, same as 1, above, DECnet
 2. *D*PRT, same as 2, above, DECnet

The reason for this is that I wouldn't use numbers, but rather a six 
character random task name, like TASK-ZYAE1Q. I believe there would be 
far less chance of clash this way.

Again, the real hang up is the monitor modification for EFTPSER.

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 VIKING, a Columbia locally developed pseudo-rsynch solution.  I 
use it between my 20's to take daily backups of development.

The FTP client and server use eight bit transfers, like DAP.
> ------------------------------------------------------------------------
> On 11/8/21 9:27 AM, Paul Koning wrote:
> 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
>> ------------------------------------------------------------------------
>> On Nov 7, 2021, at 9:54 PM, Peter Lothberg<roll at stupi.com>  wrote:
>>
>> In  the "old days" we did SMTP over DECnet, has anyone considered doing Telnet, FTP, HTTP etc over
>> DECnet transport?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sonic.net/pipermail/hecnet-list/attachments/20211108/8e855676/attachment-0001.htm>