@V7 54 2 -5
@L3 COUK1247
80
@V9 0
@YCHAPTER 16 - MUSS USER MANUAL
@G@RCHAPTER 16 - NETWORK COMMUNICATIONS@G
@V10 1 9 237
@T% 10
@BIn general, a process may send any information it wishes to
another process, in a format mutually agreed by the sending
and receiving processes. The system does not normally interpret
the information given in either the short message or in
any accompanying segment,
unless the destination process is one of the
system processes, such as a device control process.
In this case, certain conventions are assumed
for the format of messages.
These conventions are
described in this Chapter.
@S216.1 LAYOUT OF MESSAGES
@BA document to be read by system processes is assumed
to consist of a number of records.  In the case of a short
message sent to a system process, just one record is assumed to
exist in the message.
@BEach record consists of a four byte count of the number of
data bytes, followed by the data itself.  The count is equivalent
to a 32 bit integer.  This is always in a packed form so that
the first byte holds the bottom eight bits of the integer, etc.
@BThe end of a document is signified by a record with a
data count of -1.
@S216.2 COMMUNICATION WITH PERIPHERAL CONTROLLERS
@BAll connections into or out of a machine go via one of the
system peripheral control processes. These decipher the
information as it passes through, in order to decode directives
to the peripheral management system. Two types of peripheral
connection are possible, namely that with a character oriented
device and a communications line. These have slightly
different conventions, owing to their different treatment of
messages. They are, therefore, described separately below.
@SInput via a character oriented device.
@BA process controlling a device such as a terminal or paper
tape reader, has conventions for denoting the start and end of
documents and for distinguishing between input via short
and long messages. In general, a user must log a device
on to a specific process. A sequence of short messages or a
single long message may then be transmitted to that process.
@BIn the short message case, the device is
logged in by placing the command@
@
@M***M processname
@
@
at the start of a line. The device is logged in to the
named process and the remainder of the
line after the process name is passed as the
first message to the process. Each subsequent
line is passed as a separate short message
to the same process, until either a further logging
in command or a logging out
(***Z) command is detected at the start of a line.@
@BLong messages may be sent by using the logging in sequence@
@
@M***A processname
@
@
instead of ***M. The remainder of the line
after the process name is used as the header
for the long message. All subsequent input
data up to the terminator (***Z) is placed in a
segment, using the character
document conventions described earlier. The
message is then dispatched to the specified
process and the device logged out. Only
***Z may act as a terminator, and any
other sequence of
*** at the start of a line
will be faulted.
@SOutput via a character oriented device.
@BEach output device has associated with it
a particular message channel, from which it can
accept and process messages. The messages must conform
to the character document conventions described
earlier. In the case
of a device which can accept messages from
more than one process at a time, such as a
lineprinter control process, the channel is normally
set open to all processes and may not be
logged on to a specific process.
@BFor more dedicated peripherals, such as a teletype
or VDU, the device must be logged on to one specific
process and the message channel will be dedicated
accordingly. This may be achieved by sending@
@
@M***M processname
@
@
to the message channel, where the process name
specified is the one to be logged in. Quite
obviously, if the device is currently logged in,
the new log in request can only come
from the currently logged in process. A
device may similarly be logged out with a
***Z message.
@BMany output devices are regarded as being paired
with an input device, such as the keyboard and
screen of a VDU. In this case,
both "devices" will be logged in to the same
process, regardless of whether the command was
received on the input device or the
output message channel.
@SCommunication Lines
@BData transmitted via communications lines carries
additional control information which distinguishes
between the long and short message forms. This
information is inserted by the device driving
mechanism, and so only a single logging in
sequence is necessary. Thus logging in and
logging out is performed by ***M and ***Z
appearing at the start of a short
message. Apart from the examination of the start
of short messages, the data transmitted is not
inspected or interpreted by the communications software.
@BIt is anticipated that further *** commands
will be introduced to allow the transmission of
configuration information for both the character
and communication peripherals. To be defined later.
@S216.3 TALK AND BROADCAST
@BA user who is logged in can @JTALK to another user, a group of
users, or all users in the same or another machine.  This may be
achieved by typing
@
@Q 4
@
@M***T user
@Nmessages
@N***P
@0
@
@
where 'user' is either username/machine name or ALL/machine name.
The 'machine name' can be omitted when talking within the same machine.
@BRecepient(s) of the talk or broadcast messages can always
reply back, using the same method.
@BEach user can terminate its talk session and reconnect to its
process by a ***P.
@F
