IEN 158                                              Jack Haverty
                                          Bolt Beranek and Newman
                                                   1 October 1980

          XNET Formats for Internet Protocol Version 4
                          Jack Haverty
                  Bolt Beranek and Newman Inc.
                         October 1,1980

     This IEN is intended to capture in print  the  formats  used

currently  in  the  version 4 XNET protocol;  most of the data is

courtesy of Ray Tomlinson.

     Version 4 XNET is identical with version 2.5 XNET  with  the

exceptions  listed below.  The version 2.5 format is described in

RFC 643.  It should  be  noted  that  the  manner  in  which  the

protocol  is  used  by  a  user  program  (such as the PDP10 XNET

program), and by the various target-machine XNET servers, is  not

defined  herein.   In  particular  there are several problems and

heuristics in dealing with the operation of the protocol  in  the

internet environment, where individual packets may be duplicated,

lost, and reordered.

     Changes from the version 2 formats include the following:

1)  XNET header and data is embedded in a IN V4 packet instead of
    a V2.5 packet.

2)  Packet format changed  to  add  Port,  Sequence  number,  and
    Checksum fields.

3)  Change in asynchronous reply codes.

4)  Addition of ACK bit to opcode field.

5)  Positive acknowledgement of all messages.

IEN 158                                              Jack Haverty
                                          Bolt Beranek and Newman
                                                   1 October 1980

Packet Format

!                             Port                              !
!            LSB            Sequence             MSB            !
!                           Checksum                            !
!            PID                !CNT!ACK!         Opcode        !
!            LSB           Argument 1            MSB            !
!            LSB           Argument 2            MSB            !
!                                                               !
!                             Data                              !
!                                                               !

The IN protocol is set to the XNET protocol number (17 octal).

Host to target opcodes

NOP        0    No operation.
DEBUG      1    Start debugging a process or address space.
ENDBUG     2    End debugging a process or address space.
HALT       3    Halt the process.
DPOSIT     4    Deposit in memory.
RESUME     5    Resume execution of a process.
EXAM       6    Examine memory.
DSV        7    Deposit state vector (r0-r5,sp,pc,ps).
SETBPT    10    Set breakpoint.
REMBPT    11    Remove breakpoint.
ONESTP    12    Single step process (using trace trap).
PROCD     13    Proceed from breakpoint.
CREAP     14    Create a new process (or address space).
DSTROY    15    Destroy (delete) a process or address space.
XIOREP    16    Reply to XIO output (not used anymore).
XINREP    17    Reply to XIO input.
DEFALL    20    Define and allocate memory to an address space.
SAP       21    Start all processes.
SAVDSK    22    Save on disk.
GETDSK    23    Get from disk.
ENTRST    24    Enter address space into restart table.

IEN 158                                              Jack Haverty
                                          Bolt Beranek and Newman
                                                   1 October 1980

Opcodes from target to host machine.

HALTED    77    Process halted (FREEP with arguments of 0).
TRAPPED   76    Process trapped due to error.
TTRAP     75    Trace trap.
BPT       74    Breakpoint hit.
XIOIN     73    XIO input request.
XIOOUT    72    XIO output request.


     The checksum is the same as that for  the  IN  header;  ones

complement  of  ones  complement  sum of words in the packet from

Port field to last data word inclusive.  In case of an odd number

of  data  bytes,  an  additional  byte  of  zeroes is assumed for

checksum purposes.

Port number

     The port number is a unique  number  relative  to  the  host

machine  which appears in every packet for a particular debugging

session.  It is suggested that this number be  derived  from  the

time  of  day  so  that  each  session will be unique over a long

period of time.

Sequence number

     The first packet of a session (first  use  of  a  particular

port  number)  is  numbered 0.  Subsequent packets increment by 1

modulo 2**16.  Packets initiated by the target  machine  (opcodes

IEN 158                                              Jack Haverty
                                          Bolt Beranek and Newman
                                                   1 October 1980

72-77)  are also numbered starting from 0.  The target machine is

allowed to execute packets out of order but must never execute  a

packet  twice  unless  the  effect  is harmless.  For example, an

examine packet should be re-executed so  that  the  data  may  be

returned  to  the  sender.   Deposit  or resume should not be re-

executed.  The host machine is responsible for  correct  ordering

of  critical  functions.   For example, it must not send a RESUME

command until all prior deposits have been acknowledged.


     Each packet  must  be  acknowledged  by  the  receiver.   An

acknowledgement   consists   of  the  original  header  plus  any

requested   data   (e.g.   EXAM)   with   the   ACK   bit    set.

Acknowledgements   are   not   cumulative;   an   acknowledgement

acknowledges only the  one  packet  with  the  matching  sequence

number.   If  the  target debugger is incapable of performing the

requested function, it should set the CNT (can't) bit instead  of

the  ACK  bit.  Both bits may be set meaning that the function is

available but the data required is  no  longer  available.   This

might be the result of a duplicate packet.