[Info-vax] Rethinking DECNET ?

[Johnny Billquist]

On 2014-09-02 09:52, Dirk Munk wrote:
> JF Mezei wrote:
>> On 14-09-01 19:41, Dirk Munk wrote:
>>
>>> decades ago. You can still use Decnet 4 if you like, but JF is now
>>> asking to overhaul Decnet 4 to use it over IP (IPv4 and IPv6?). Decnet 5
>>> can be used over IPv4 and IPv6,
>>
>> I don't care about decnet protocol itself, whether 4 or 5. I care about
>> the integration of decnet within the operating system/file system.
>>
>> aka: everywhere you can have node::  (at DCL, application etc).
>>
>> I mention DECNET 4 because it has NCP which defines network objects,
>> and AUTHORIZE has the proxy database.
>>
>> So if there were a way to port various network objects such as FAL to
>> become native on IP instead of DECNET, it would allow one to continue to
>> support the same functionality provided by the node:: in many places
>> used by the user, without needing an actual DECNET network stack since
>> the objects would be native to IP.
>
> I get your point JF, but what your are describing here is not Decnet
> over IP but adding functionality to the IP stack. FAL functionality
> would get a separate IP port number. But Decnet FAL will also do file
> conversions if necessary. That is because it was designed for operating
> systems that know file types, various types of sequential files,
> relative files, indexed and so on. Unix doesn't have that, a Unix file
> is just a load of bytes. Unix and IP are far more primitive in that
> respect. FTP for instance will do a 'file conversion' with ascii files.
> If you use ascii FTP to copy a file from Windows to Unix, the <cr><lf>
> end-of-record terminators will be replaced by <lf>, but that is about
> it. You will have to tell FTP that it is an ascii file if the file type
> is unknown (not .txt for instance).

Right.
Even more complicated is the fact that DECnet works in slightly 
different ways than TCP. Subtle, but important. And grafting those 
changes into a TCP solution could be "interesting", but required to 
retain some DECnet semantics. (For example, DECnet can carry a small 
load of data in the connection request, and the server can read out this 
data before deciding if it will accept or reject the connection. And 
DECnet also can carry authentication information in the connection 
request, which is handled by the network stack before the request even 
reaches the server.)

FAL is not a problem per se. Once you have done the whole DECnet using 
IP solution, the existing FAL and DAP code should work as is, and two 
VMS boxes would talk and access files like before with no problem.
The question then becomes how FAL and DAP would work on a Unix system. 
But that question have also already been addressed, since both Ultrix 
and OSF/1 already did this.

>> (so tunneling DECNET 5 over IP is not the same as having FAL be native
>> on IP).
>
> It is >>not<< tunneling. Decnet 5 uses TCP+IP as transport layer instead
> of OSI. Decnet 5 hosts have IPv4 and/or IPv6 addresses and BIND DNS
> names, not OSI addresses in this case. In fact Decnet 5 is doing exactly
> what you're asking from a redesigned Decnet 4 stack, however it is using
> only one TCP port, port number 102.

You know, this actually *is* tunneling. :-)
You have one DECnet stream over TCP/IP. Inside that stream goes DECnet 
traffic, which might actually be several different streams that are 
multiplexed on this tunnel. And DECnet have no idea how the two 
endpoints connect, and how many hops might be along the way in the IP 
world. It's a tunnel.

	Johnny