20 Aug
2021
20 Aug
'21
12:16 p.m.
On Aug 19, 2021, at 4:45 PM, Paul Koning
<paulkoning at comcast.net> wrote:
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.
On Aug 19, 2021, at 4:37 PM, John Forecast via
cctalk <cctalk at classiccmp.org> wrote:
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.
On Aug 19, 2021, at 9:37 AM, Bill Gunshannon via
cctalk <cctalk at classiccmp.org> wrote:
On 8/19/21 12:23 AM, Warner Losh via cctalk wrote:
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. On Wed, Aug 18, 2021 at 10:07 PM Bill Degnan
<billdegnan at 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. 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