> On Aug 19, 2021, at 4:45 PM, Paul Koning <paulkon...@comcast.net> wrote:
>
>
>
>> On Aug 19, 2021, at 4:37 PM, John Forecast via cctalk
>> <cctalk@classiccmp.org> wrote:
>>
>>
>>> On Aug 19, 2021, at 9:37 AM, Bill Gunshannon via cctalk
>>> <cctalk@classiccmp.org> wrote:
>>>
>>> On 8/19/21 12:23 AM, Warner Losh via cctalk wrote:
>>>> On Wed, Aug 18, 2021 at 10:07 PM Bill Degnan <billdeg...@gmail.com> wrote:
>>>>> pretty cool
>>>>>
>>>> Thanks! Looking at the boot source I figured out that I just needed to
>>>> build a non-generic kernel
>>>> to get rid of the load device prompt... I'd somehow omitted that during the
>>>> install...
>>>
>>> I always skip that during the install. Much safer to do it
>>> later when I am sure I have a stable system. Need to add
>>> serial devices and network device. I wonder if the DECNET
>>> daemon from Linux would back port to Ultrix-11? CLient side
>>> is provided, but no daemon that I am aware of.
>>
>> If by daemon you mean the kernel code supporting NSP and routing protocols
>> then, no, it would not be an easy back port, that code makes heavy use of
>> Linux-specific functions and capabilities. The user-level utilities would be
>> much simpler but you would need to copy over the DECnet header files and
>> implement the expected library routines (getnodebyname(), getobjent() etc).
>>
>> John.
>
> Does Linux follow the DECnet socket services of Ultrix, or are they
> different? I remember that Ultrix had socket operations matching the power
> of the DECnet application interface, stuff like connect data or
> packet-oriented data transmission. It also supported a basic stream service,
> which was mapped (somehow -- I'd like to find the details) onto the
> underlying DECnet packet service.
>
As far as I can see they both implement the same socket level interfaces for
I/O, there are some differences in some of the ioctl calls which are OS
dependent. The base socket interface does not have the concept of optional data
on connect/disconnect or even the difference between disconnect and abort so
these are all implemented as ioctls and library routines are provided for
common use cases. DECnet supports 2 types of socket; SOCK_SEQPACKET which
maintains message boundaries just like other DECnet implementations and
SOCK_STREAM which provides a TCP-like byte stream interface. All of the
standard DEC utilities use SOCK_SEQPACKET and both ends of a link need to be of
the same type for this to work correctly. SOCK_STREAM sockets transmit data as
soon as it’s supplied (assuming flow control allows transmission) and a receive
operation reads as much data as is available (subject to the user read request
size) so, in this case, message boundaries can change from run to run.
> I've been thinking it would be neat to have an httpd that answers DECnet
> connections (object number 80, of course).
>
That should be relatively easy depending on how you want to delineate message
boundaries. SOCK_SEQPACKET would be the easiest and should work against all
DECnet implementations. If you use SOCK_STREAM with embedded message lengths,
you need to make sure that the last byte of a message is also the last byte of
a user-level write operation so EOM is set correctly and the remote end will be
able to read the message without getting stuck waiting for EOM to be set. In
general, SOCK_STREAM communication is only useful when talking to other systems
which also implement SOCK_STREAM semantics.
John.
> paul
>
>
