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.
Checksum
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.
Acknowledgements
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.