Dodo

Dodo Services - XNS with Java

Dodo Services implement Xerox Network Services (XNS) protocols in Java, providing XNS services to existing emulated or real Xerox client machines.

Currently the following XNS services are provided by Dodo:

• Time
• Routing Information
• Clearinghouse
• Authentication
• Boot
• Printing
• Filing
• Mailing
• External Communication

(although in most cases the implementation is incomplete regarding the specification, the services provide a working and useful subset for working "as usual" with XDE resp. StarOS, ViewPoint or GlobalView resp. Interlisp-D.

In fact, Dodo is not a single Java program, but a set of programs creating a simple virtual network infrastructure, a kind of XNS-over-TCP/IP. This virtual network allows different programs to inter-connect, among them the Dodo server proper, a gateway to a (real) network device and of course the Xerox client machines wanting to access the server component (see section Topology).

As for the maybe exotic name: although Dodo is not based on the Mesa-architecture but an almost pure Java implementation, the name had to start with the letter D to be in line with the Xerox tradition; on the other hand, it seemed appropriate to be something that no longer exists or is not noticeably present in the world; so the extinct species of a flight incapable bird came in mind: the Dodo.

Functionality

The Dodo system implements large parts of the Xerox Network Services protocol stack in Java, providing the functionality to build higher-level things like XNS file or print services.

In the XNS levels terminology, the Dodo system supports resp. implements the following protocols:

• Level 0
  Ethernet over TCP/IP as transmission media: raw Ethernet packets are relayed by the NetHub program between machines connected to the NetHub; although any ethernet packets are transported, only packets with ethertype 0x0600 (XNS IDP) are processed by the Dodo server and thus relevant here (hence narrowed to XNS-over-TCP/IP).

• Level 1
  IDP (Internet Datagram Protocol) packet structure, transporting the basic XNS addressing information

• Level 2

  • PEX (Packet EXchange)
    API for both responder (server-side) and requestor (client-side)
  • SPP (Sequenced Packet Protocol)
    API both server-sockets and client-connections, including the connection close protocol (based on sub-sequence types 254 and 255)
  • Echo
    responder for echo protocol packets
  • Error
    incoming error packets are dispatched to the local component reported by the sender as having produced the problem

• Level 3

  • Time of Day protocol
    responder for time request broadcasts
  • Routing Information protocol
    broadcaster for routing information as well as responder to client requests
  • Courier
    infrastructure for implementing Courier server programs;
    however no Courier compiler is currently available, so mapping the Courier program definitions (.cr files) to the corresponding Java constructs must be done manually.

• Level 4

  • Broadcast for Servers (BfS)
    responder for Clearinghouse BfS and Authentication BfS requests
  • Boot Service
    responder providing boot-files (microcode, germ, boot-file) to a requesting machine, supporting both the SimpleRequest/SimpleData and SPP variants of the boot protocol
  • Clearinghouse (CHS)
    (Courier program 2, versions 2 and 3)
    all protocol procedures are implemented for a read-only clearinghouse database, allowing to log in to XDE, Star/Viewpoint/GVWin and Interlisp-D, to navigate the network directory in GlobalView as well to query clearinghouse entries with Maintain.bcd in XDE; however changes to the database are rejected
  • Authentication (Auth)
    (Courier program 14, version 2)
    all protocol procedures are implemented for a read-only clearinghouse database, allowing to log in to XDE, Star/Viewpoint/GVWin and Interlisp-D; however changes to the database are rejected
  • Printing
    (Courier program 4, version 3)
    all protocol procedures are implemented, allowing to print from XDE, Star/Viewpoint/GVWin and Interlisp-D as well as to query a print job status, the printer properties and the printer status.
    The interpress files are received and collected in the output directory, a PostScript file can optionally be generated for the interpress master. and possibly post-processed.
    The PostScript generation provides a basic support for western-european character sets as well as simple graphics (vector and uncompressed bitmaps), giving usable but far from perfect results.
  • Filing
    (Courier program 10, versions 4,5,6)
    a large subset of the protocol procedures is implemented, allowing to access file drawers, folders and files on Dodo XNS File services from XDE, Star/Viewpoint/GVWin and Interlisp-D. Although substantial functionality is missing (like access control and access rights), Dodo file services are already usable in a mostly single-user environment.
  • Mailing
    (MailTransport: Courier program 17, version 4 and 5)
    (Inbasket: Courier program 18, version 1 and 2)
    the subset of protocol procedures actively used by XDE, Star/Viewpoint/GlobalView and Interlisp-D for sending and receiving mails is implemented.
  • External Communication
    (Gateway Access Protocol: Courier program 3, version 3)
    all protocol procedures are implemented, providing access to "foreign systems" through plain telnet (simulating RS-232C/TTY lines), tn3270 telnet (simulating 3270 BSC/SDLC attachments to emulated or real IBM-type mainframes) or stdin/stdout piping to local commands/scripts.
  • NStoPupHostLookup
    (Interlisp-D specific)
    Responder for delivering the PUP network and host numbers for a machine

The network configuration of a Dodo server instance and the services provided can be configured through a property file specified when starting the Dodo program.

Topology

The following network example from the "old days" can be used for discussing the Dodo components:

The client part of the network features several workstation generations from 8010 Star and 6085 with XDE workstations (both could also run ViewPoint or Interlisp) to a PC running GlobalView.
The server part of the network has the most common XNS backends like the required Clearinghouse/Authentication Service (also hosting a Mail Service) as well as the usual File and Print Services. Interactive access to "foreign systems" like mainframes or mid-range systems is provided through an External Communication Server with its companion CIU (Communication Interface Unit).

In a more contemporary environment of emulated Xerox machines, the original Star 8010 workstation could be subtituted by the Darkstar emulator, the Dwarf emulator could replace the PC with GlobalView.
But the are still functioning Xerox workstations that may require XNS services, so the 6085 machine will be assumed to be such a machine.

The above network could be reproduced as follows with the XNS emulation provided by the Dodo components:

Besides the XNS client systems, at least 2 components need to run as independent programs for using Dodo services:

• NetHub
  this is the backbone of the virtual network, to which all other components connect with a TCP connection. The NetHub forwards each packet received from one attached component to the other connected components.
  In a sense, NetHub is the equivalent to the thick yellow coaxial ethernet cable in the 80's to which each Xerox workstation was connected through a transceiver tapped on the cable.
  NetHub uses a quite simple protocol for communication with connected client components: the raw ethernet packet to be transmitted is prefixed with a 2 byte big-endian length information. This protocol is simple enough to be easily implemented in emulators.
  NetHub listens on port 3333 for client connections (currently hard-coded).

• Dodo server
  this is the program providing the XNS services. All supported services (clearinghouse, authentication, filing, printing etc.) can be provided by a single Dodo server instance, i.e. a single running Dodo server process, which connects to the NetHub.
  The only exception is printing, as the Courier protocol for printing only supports one printer service for a server machine, so each additional emulated print service therefore requires another Dodo process (using an own machine-id).
  It is however possible to distribute the provided XNS services over several Dodo server processes connected to the same NetHub, for example one Dodo server for the clearinghouse, authentication and mail services as well as the filing volume for desktops and user file drawers, a second for printing and a third for some data filing volumes. In such a distributed case all Dodo server instances must use the same clearinghouse database files (shared or identical copies).

Besides programs (emulators and Dodo server) connecting directly to the NetHub, other XNS clients can also use the Dodo XNS services through the NetHubGateway: this is a NetHub client program that connects to a local PCap network device, implementing a gateway for XNS packets between a (more or less) real network and NetHub, allowing to attach emulators or potentially real machines that do not directly implement the NetHub protocol.

Two additional program components of Dodo services can be used if required:

• NetSpy
  this is a "read-only program" connecting to the NetHub with the only purpose to receive all packets traveling in the virtual network and to dump the packet content to stdout; in addition to the raw packet content, it issues the reco