AD-A021 072 MSG; THE INTERPROCESS COMMUNICATION … · Agency of the Department of Defense and...

U.S. DEPARTMENT OF COMMERCE National Technical Information Service

AD-A021 072

MSG; THE INTERPROCESS COMMUNICATION FACILITY FOR THE

NATIONAL SOFTWARE WORKS

PRELIMINARY

BOLT BERANEK AND NEWMAN, INCORPORATED

PREPARED FOR

ROME AIR DEVELOPMENT CENTER

23 JANUARY 1976

T iri-wmnn-T -

Best Available

Copy

KEEP UP TO DATE Between the time you ordered this report—

which is only one of the hundreos of thou- sands in the NTIS information collection avail able to you—and the time you are reading this message, several new reports relevant to your interests probably have entered the collection.

Subscribe to the Weekly Government Abstracts series that will bring you sum- maries of new reports as soo/7 as they are rereived by NTIS from the originators of the research. The WGA's are an NTIS weekly newsletter service covering the most recent research findings in 25 areas of industria1. technological, and sociological interest— invaluable information for executiver and professionals who must keep up to date.

The executive and professional information service provided by NTIS in the Weekly Government Abstracts newsletters will give you thorough and comprehensive coverage of govern nent-conducted or sponsored re-

search activities. And you'll get this important information within two weeks of the time it's released by originating agencies.

WGA newsletters are computer produced and electronically photocomposed to slash the time gap between the release of a report and its availability. You can learn about technical innovations immediately—and use them in the most meaningful and productive ways possible for your organization. Please request NTIS-PR-205/PCW for more information.

The weekly newsletter series will keep you current. But learn what you have missed in the past by ordering a computer NTISebfch of all the research reports In your area of Interest, dating as far back as 1964, if you wish. Please request NTIS-PFMSS/PCN for more informatici.

WRITE: Managing Editor 5285 Port Royal Road Springfield VA 22161

Keep Up To Date With SRIM SRIM (Selected Research in Microfiche) provides you with regular, automatic distribution of the complete texts of NTIS research reports only in the subject areas you select. SRIM covers almost all Government research reports by subject area and/or the originating Federal or local government agency. You may subscribe by any category or subcategory of our V/GA (Weekly Govern- ment Abstracts) or Government Reports Announcements and Index categories, or to the reports issued by a particular agency such as the Department of Defense, Federal Energy Administration, or Environmental Protection Agency. Other options that will give you greater selectivity are available on requesl.

The cost of SRIM service is only 45^ domestic (SOt4 foreign) for each complete

microfiched report. Your SRIM service begins as soon as your order is receive^ and processed and you will receive biweekly shipments thereafter, 'f you wish, your service will be backdated to furnish you microfiche of reports issued earlier.

B' cause of contractua' arrangement? with several Special Technology Groups, not all NTIS reports are distributed in the SRIM program. You will receive a notice in your microfiche shipments identifying the excep- tionally priced i'epo is not available through SRIM.

A deposit account with NTIS is required before this service can be initiated. If you have specific questions concerning this service, please call (703) 451-1553, or v-rite NTIS, attention SRIM Product Manager.

This information product distributed by

|yP|,«S U.S. DEPARTMENT OF COMMERCE ■^ ■ «^ National Technical Information Service

5285 Port Royal Road Springfield, Virginia 22161

,O0OT RERANEK AND NEWMAN INC

COM SUITING 0 E V I I O P M J N T R £ S t A t C H

(^

o

iiBN Report No. 3237 January 1976

•a: MSG: The Interprocess Communication Facility for the National Software Works

Preliminary

January 23, 1976

NSW Protocol Committee

This work was supported by the Defense Advanced Research Projects Agency of the Department of Defense and monitored by Rome Air Development Center under contract number F3060I-76-C-Ct*94 and by the Office of Naval Research under contract number N|014-75-C~0773.

jP Reproduced by

^ NATIONAL TECHNICAL INFORMATION SERVICE

US D«p»rim.n« o( Commcrc« Sprmjin-.d. VA. 22151

PRICES SUBJECT TO CHANßt IOJTON WAirllNGTON CHICAGO HOUSTON LOS ANGElCS OXNAiD SAM PiANClSCO

i -iirnnfiiwir "~'"aa-l*A— T M ■ r "if i i.i,-Tii

—üoclaasj £jjBd StCURlTY CLASSiriCATlON OF TH'Ü ÂOC (Whmn DM» Knffd)

REPORT DOCUIAENTATIOH PAGE \ nrsom SUMIEII

BBN Report No. 32 37

READ rNSTRUCnONS BEFORE COMPLETING FORM .

12. COVT ACCCMION NO B. «CCl^ltMT'S CATALOG NUMBER

«• TITLE fanrfSuöflff«)

MSG: The Interprocess Communication Facility for the National Software Work^ (Preliminary)

i. TYÊ OF «EPORT A PFRIOO COVERED

Scientific •. RERFORMING ORG. fERORT NUMBER

7. AUTNOA


• ■ CONTRACT OR GRANT NOMBERfiJ

N0014-75-C-0773

* PERFORMING ORGANIZATION N AN£ AND ADDRESS

Bolt Beranek and Newman Inc. u

50 Moulton Street Cambridge, Massachusetts 02138

Hi PROGRAM ELEMENT. PROJECT. 1 ASK ^«»EA i WORK UNIT NUMBERS

M. CONTROLLING OFFICE NAME AND ADDRESS «2. REPORT DATE

Defense Advanced Research Projects Agencî Information Processing Techniques

Arlington. VA ]4Clfl Wi l^nr. RUM P« MONITORING AO'iNCV NAME A

»3. NUMBER O» PAGES

7V-

Office of Naval Code ONR-430D 800 N. Quincy Street Arlington, Virginia

ADDRESV'f dfttannl fro« ControlHng Ollte»)

Research 18. SECURITY CLASS, (of thlt r«por<>

Unclassified

22217 IS«. OECLASSiFiCATlONTDÖWNGRADINO

SCHEDULE

t«. DISTRSPUTION STATEMENT (ol thlm Report)

Distribution of this document is unlimited. It may be released to the Clearinahouse, Department of Commerce for sale to the general public.

!T. DISTRIBUTION STATEMENT (ol rh« «balract Mtf^rcd in Block 20. II dl/l»/«ot from Roporf)

ie SUPPLEMLNTARY NOTES

(a) This research supported by DARPA under ARPA Order No. 29 01 (b) This report also published by Massachusetts Computer

Associates, Document No. CADD~7601-2611.

19. KEY WORDS CConflnuo on rorora* »Id* II n»c**rmry and IdiMlty by block numbmr)

National Software Works Computer Networks Interprocess Communication

Distributed Systems Network Protocols Resource Sharing

20. ABSTRACT (Contlnv on rovar«* «Id« II nac*««orjr mnd Identity by block lumbur)

This report describes the communication fac which was developed to support interprocess the implementation or the National Software more important of the processes which compr pattern of communication which those proces described. Next from those patterns a mode communication which is sufficient for NSW i Finally, tho Hfîi^ of fh^ MSG facil.itv .it.

ility, named MSG communication for Works (NSW). The ise NSW and the ses require are 1 of interprocess s abstracted. a^lf ATP dPVPlnppd.

DD ,^11473 EDITION Of 1 NOV (JS IS OBSOLETE Unclassified SECURITY CLASSIFICATION OF THIS PAGE fWiao Dara Entafa.f)

I

OLT BERANEK AND NEWMAN .NC

CONSULTING D E V f I O P M E N T RESEARCH

MSG: The Interprocess Conrnunication Facility for the National Software Works

Preliminary

January 23, 1976


Massachusetts Computer Associates Inc. Document no. CADD-7601-2611 Bolt Beranek and Newman Inc. Report no. 3237

This work was supported by the Advanced Research Projects Agency of the Department of Defense and monitored by Rome Air Development Center under contract number F30602-76-C-009^ and by the Office of Naval Research under contract number ri0014-75-C-0773.

1(0^

-^.

BOSTC; WA5H14GTON CHICAGO HOUSTON IOS ANGCIES OXNA

-- n i

♦ ^_X«AUCliCO

The NSW Protocol Committee

The NSW Protocol Committee in an ad hoc proup made up ^f representat ves from Bolt Beranek and Newman Inc. (BBN) and Massachusetts Computer Associates Inc. (Compass). The committee members are (in alphabetical order) Paul Johnson (BBN), Robert Millstein (Compass), Stuart Schaffner (Compass), Richard Sch^ntz (BBN), and Robert Thomas (BBN). The concepts embodied in this document are jointly the work of these five people. Special mention should po to Robert Thomas and Stuart Schaffner who wrote major portions of the document. Others contributinp; to the conceptualization of the MSG facility include Don Andrews (SRI), Robert Braden (UCLA), Kirk Sattley (Compass), Ken Victor (SRI), and Doug Wells (MIT).

iCH

MSG Design Specification 1/23/76 TABLE OF CONTENTS

Section 1 - Introduction

1. 1 Overview 1 -1 1 .2 NSW Components 1-2 1.3 Patterns of conmunication 1-3 1 .^ Model of Conmunication 1-6 (.5 Modes of Communication 1-7 1.6 Seruencinp of Messages 1-10 1.7 Host Incarnations 1-11 1.8 Organization of this document 1-12

Section 2 - MSG Process Environment

2.1 Hosts 2-2 2.2 Processes 2-3 2.3 Process names 2-4 2.^ Process addressmp; modes 2-5 2.5 Modes of information transfer 2-6 2.6 MSG primitive operations 2-8 2.7 Signals 2-15 2.8 Information transmittal 2-16 2.9 Sequencing of messares 2-18 2.10 Process creation and termination 2-21 2.11 Summary of terms 2-22

Section 3 - MSG-to-MSG Protocol

3-1 Transaction Identifiers 3-2 3.2 On the use of "sourcen and "destination" 3-3 3.3 MSG-to-MSG Protocol Items 3-U

Section 4 - MSG-to-MSG Protocol for the ARPANET

4.1 Implementation of MSG-to-MSG Paths by ARPANET Connections 4-1

4.2 Establishing the ARPANET Connections 4-2 4.3 Breakinp the ARPANET Connections 4-4 4.4 Authentication of MSGs 4-5 4.5 Error Contrc I for MSG-to-MSG Paths 4-8

Section 5 - MSG-to-MSG Transmission Formats for the ARPANET

5.1 General Format for MSG-to-MSG messapes 5-2 5.2 Formats for Messare Components 5-3 5.3 Identifyinr Transactions 5-6 5.4 MSG-to-MSG Protocol Messares 5-7 5.5 Summary of Commands 5-15

ii

_____

MSG Deslrn SoecificRtion 1/23/76

1. Introduction

1.1 Overview

The National Software Works ( inplenenters with a suitable envir prorrams. This environnent conr.is tools (such as editors, compilers, variety of computer systems, but a access-rrantinr, resource-allocati uniform file system. By its very processes distributed over a numbe communications network. Ihese pro one another in order to create a u describes the communication facili developed to provide interprocess implementation of the NSW, The co is currently the ARPANET. However, MSG facility to be as independent implementation so that the concept implementations on other networks.

NSW) provides software onment for the development of ts of many softv/are development and deburpers), runninr on a

ccessible through a single nr monitor with a single, nature, the NSW consists of r of computers connected by a cesses must communicate with nified system. This paper ty (named MSG) which was communication for the mmunications network we have designed the

as possible of the ARPANET s may be carried over to

We berin by describinf the more important of the processes which comprise NSW and discussing the paLtern of communication which those processes reouire. We then proceed to abstract from those patterns a model of interprocess communication which is sufficient for NSW. Finally, we develop the details of the MSG facility itself.

It is our hone that both the description of the process of defining MSG as well as the description of the structure of the protocol will be of interest to protocol developers for the ARPANET and oche»- networks.

Introdjct idi 1-1

■ --

Mi3G Design Specification 1/23/76

1.2 NSW Components

The monitor of NSW is the Works Manager,. It is responsible for servicinp- requests for system resources - e.p., runninp a tool, opening a file. The Works Manarer verifies that each such request is valid (usinp in this verification a rather elaborate access data base which serves as a domain for automated project management machinery). The Works Manager then allocates to each valid request th^ necessary resource. This allocation generally involves either the creation of a tool (e.g., editor, compiler) instance - i.e., the creation of a new NSW process - or the movement of a file (which movement may be either inter- or intra-host).

^or each user of NSW an interface to the other components is provided by a Front End, which may be loca± to the user. In the sequel we will talk as if the Front End were local, so that communication to the user is synonymous with communication to the Front End. This is not, however, an NSW system requirement. The Front End filters the user's input stream, discarding bad characters (e.g., control-C should not be sent to TENEX tools) and interpreting system-wide control characters - delete line, retype line, escane to the Works Manarer, etc. In addition, the Front End may provide local parsing of the Works Manager command language and, conceivably, even tool command languages.

Just as users see the NSW environment through the Front End, so also do )Ols see an extended local system environment through a Foreman component. Tools are software systems which are written for riven host - e.g., MULTICS. To become NSW tools they must be inserted into a slightly different milieu. This different milieu is provided by a Foreman component on the tool's host. The Foreman provides the tool with access to NSW resources, such as NSW files. Thus a tool gets NSW resources by making a local call on the Foreman, which then forwards the request to the appropriate NSW component. From the viewpoint of other NSW components, then, it is the Foreman rather than the tool with which most communication must occur.

Introduction 1-2

—---

MSG Dorian SpecifiOrit ion I/;M/7^

1.? Patterns of conûnioation

Wo will nov; describe the anticipated patterns of corminicat ion hetv/een the NSW processes. These connunicat ion: factor into six types:

Front Krü - Works Manarer tool/Foreman - WorLs Manarer Works Manaper - File Packare Front End - tool/Foreman tool/Foreran - tool/Forenan File Package - File Packare

The other nossihi- pairs - e.P"., Front End - File Packare, File Packare - tool/Fcvnan - do not represent connunication paths in NSW.

Frone End - Wor' s Manager

use Wor Fnd del use a In res hit - c nin be pro Pan lin bet Wor whe res sea

ConnuniCc r requests ks Manarer ). Exanpl( etc a file r nay Make ost all re( ponse to er s . The t ii ortainly or utes betwe« processed cessed any aêr share k need not ween resoui ks Manager re each el ponse, and uence .

at ion "-et ween these two kind for NSW resources (Front En responses to such requests

es of such i ^'.ests are: run , etc. Ti.esc reouests are re only a few per r.our. Each

nuests can easily se encoded ach rennest is also ^hort - ne reouired t^ process a rea n the order of milliseconds en requests. 1here is no no by the sane inst'n-e of the previous reauest (since all the sane c onn o n data base). be retained between a Front

rce requests. Thus we can c connunication as i sequence

eênt is a short reauest, a a 1o n r d e1 a v until the next

;■• of process

(W

consists of to Works Manarer) and

o Front file, e n t - a

Works Manager t a tool , copy a latively infrecu request is short In 1000 bits,

a r a i n, less than UPst is renerail ^5 conrared to t cessity for a re Works ilanarer th instances of th Hence a connun

End '-nc. i Works haracterize Fron of unrelated el

I ■» r i e f delay, a r elenent o^ the

The moo

v brief he quest to at e Works i cation Mana «êr

t End - e n e n t s , h o r t

. tool/Foreran - Works Manager

These connunications arc exactly analorous to Front End - Works Manarer connunications. A. tool (on behalf of a user) requests an NSW resource of the Works Manarer. Examples of such requests ire: open a file, create a subsidiary tool process, deliver a file, etc. As above, these requests are generally less than 100C bits, are processed by the Works Manarer in

Introduction

1-3

MSG Desipn Specificaticn 1/23/76

millisecond?, have responses of less thnn 1000 bits, and rre relatively infrequent. The only difference between this pattern and the preceding pattern is that tool requests are none frequent than Front End requests, althourh the tine between such revests is still measurable in rrnutcs.

. Works Manarer - File Package

These communications are arain analoFous to the above. Indeed, these requests (of the Works Manarer to the File Package) occur in order to service a Front End or tool request of the Works Manager. For example, when a tool asks the Works Manarer to open a file, the Works Manager must then ask a File Package process to make a copy of that file, possibly across the ARPANET. The time oO make a cross-net copy of a file may be measured in seconds (even in minutes for larpe files), but such lonr copies are expected to be infrequent. Thus, the sane pattern of a short request (not related to previous requests), a brief delay, a short response, a Icp delay holds for Works Manarer - File Packape communication also.

. Front End - tool/Foreman

Communication between these processes consists of user commands to tools and tool responses to users. In some cases these communications will fit into the same pa'^ern as the three previous oases. Often, however, the pattern is different. Consecutive requests are related and must be serviced by the same tool. The tine Iritween the user's command and the tool's response may be preater than the time between the response to the previous command and the issuinp of the next command. Also, the freouency of user commands to tools may be much greater than the frequency of either user or tool requests to the fork's Manarer. In addition, the lenrth of a Front End - tool/Forer.an communication may be larp-e For example, in a typical session a user ni^ht request the us0 of a text editor ( Front End - Works Manarer communication), ret a particular file to edit (tool/Forer.an - Works Manarer communication), and then insert two hundred lines of prop-ram text into that file. Thus Front End - tool/Foreman communication is exoected to vary from the infrequent, short request pattern to frequent, lonr transmissions of information.

. tool/Foreman - tool/Foreman

These communications are relatively infrequent. No tool currently installed in NSW needs to talk directly to another tool. Nevertheless, deburpinr tools for NSW as well as multi-process cools have been proposed and are heinr implemented.

Introduct ion

-SSff^SSiSÜ ithrrrr

HSG Design Spocifioatlon l/^S/TC

Such tools require connunication facilitier,. We expect that their oatterns of connunication will he analoroua to Front En tool/Foreman oonmunications.

. File Packare - File Packafe

i

Some very small fraction of these communications will consist of short, infrequent messages - o.n-., a source File Packard tellinc a destiration File Packare the lenrth and encodement of a file - but the hulk of such communication wil1

consist of files beinr transferred. Thus, UP can characterize this pattern as infreouent transmissions of many bits.

Um

I»*

Introduction

1-5

L-,". —rih ri —y

"Tnili «*

i! IWIMiWIIHIWJWiWmMWIllli WPIWWIU-^MJ» III ■! f IIMJW

MSG Design Specification 1/23/76

',H Model of Communication

^rom these expected patterns of communication we can abstract a. model of the kind of interprocess protocol that NSW reauires. Wo have, roughly speakinp:, three patterns of communication:

. Infr?auent short transactions between previously unrelated processes (Pattern 1):

Front End - V/orks Moiaper tool/Foreman - Werks Manager Works Manager - File Packape

. More frequent, longer t'.'ansactions between related processes (Pattern 2):

FroHw End - tool/i'oreinan tool/Foreman - tool/Foreman

. Infrequent, very lon^ transactions (Pattern 3)-* File Package - F^'le Package.

L.troduction 1-6

M i ii IMiHMMaitniniiiinrtii—^—- —

MSG Desipn Cpecifloat ion 1/23/76

1.5 Modes of Comnunication

tISG supports theso NSW patterns of communication by providing tv;o different nodes of process addressinr:

. reneric addressinr;

. .specific addressinr;

and three different nodes of communication:

. nessapes*

. direct communication paths (connections);

. alarms.

Lach mode of orocess addressinr and communication is intended to satisfy certain NSW renuirements and to be used in certain kinds of situations. H^weve^, MSG itself does not impose any Irritations on how rrocesL.^s '^e the various communi ation nodes. MSG does not interpret nessarcs or alarms, nor oes it intervene in communication on direct connections. The interpret'-: t ion of nessares, alarms, or direct connections is et.tirsly •■ matter for the processes uslnr MSG to communicate.

ed by processes which either have r which the details of any past It is restricted to the nessape

id reneric address inecifies -c en MSG accepts a renerically as destination sone process which is addressed but has also declared its rically addressed message. If there reate one. Pattern 1 communication ansmission of a renerically

Generic addressinr IS U3 noo communicated before or fo comnunication is irrele vant. mod e of communication. A val fun ctiocal process clas s . Wh add rcssed message it se 1 .3 C t S not only in the generic c 1 ^ s s wil lin^ness to receive a fene is nc such process, MSG nav c is always initiated by the tr add ressed nessd^e.

A valid specific address refers t this address remains valid for the lif Specific addressinr nay be used with fx nodes. Specific addressinr is used Detween processes w familiar with each other. The familiarity is renerallv the processes hav communicated with each other before, directly or through intermediary processes.

o exactly one process and e of that process. 11 three communication

which are y because

either

Messare exchange is provided by MSG to supper: the requirements of pattern 1 comnunication and sone pattern ? comnunication. It is expected to be the nost common node of comnunication anonr NSW processes. To send a message, a process

Introduction 1-7

I ---"^ririn -— i ■ in ii i - —T


addresses it by specifying the address of the process to receive the message and then executes an MSG "send" primitive which requests MSG to deliver the message. When MSG delivers a message to a process it also delivers the name (i.e., specific address) of the process that sent the message.

The second mode of MSG communication is direct access communication. A pair of processes can request that MSG establish a direct communicacion path between them. Direct communication paths are provided to support the requirements of pattern 3 communioatxon, such as file transfers between hosts, and some pattern 2 communication, such as terminal-like communication between a Front End and tool/Foreman. (The ARPANET realization for a direct communication path is a host/host corinection or connection pair.)

The alarm mode of communication is supported by MSG to satisfy a communication requirement typically satisfied by interrupts in other interprocess communication systems. Alarms provide a means for one process to alert another process to the occurrence of an exceptional or unusual event. Processes may send and receive alarma much as they send and receive messages. However, tnere are significant differences between alarms and messages. The rules that govern the flow and delivery of alarms are different from those that govern the flow and delivery of messages. In particular, the delivery of an alarm to a process is independent of any message flow to the process. 'i>at is, the delivery of an alarm to a process cannot be blocked by any messages queued for delivery to the process. Unlike a message which can carry a substantial amount of information, the information conveyed bv an alarm is limited to a very short alarm code. Th_s limitation implies that the deli' ^ry of alarms can be accomplished in a way that requires little i» the way of communication or storage resources. This makes it possible for MSG to insure certain "priority" treatment for alarms which makes them suitable for alerting processes tc exceptional events. While similar to traditional interrupts, alarms are different in one important respect: the delivery of an alarm to a process does not necessarily imply that the process is subjecwßd to a forced transfer of control by MSG. For this reason, we have chosen to use th? term alarm rather than interrupt.

All modes of interprocess communioation supported by MSG follow the same basic pattern, which is roughly as follows:

1, One process tells MSG about a message or alarm to be sent or a connection to be opened. It also specifies a cestination address and a signal by which MSG can

Introduction 1 3

- - - •■ - - - — 1 aaa

MSG Desirn Specification 1/23/76

inform it that the message or alarm has been sent o: the connection opened.

2. Another [recess which matches the above destination address tells MSG that it is rsady to receive the same type uf communication. It also specifies a sipnal by which MSv can inform this nrocess that the messare or alarifi has been received or the connection opened.

3. MSG send.^ the alarm or messape or opens the connection It also signals the source process that the messare or alarm has been sent or the connection opened and sirnals the destination process that the messape or alarm has been delivered or the connection opened. After it receives the sipnal, the process receivin.7 a messape or alarm always knows the specific address of the sender.

Introduction 1-9

^^^


1.6 Sequencing of Messages

Normally MSG does not guarantee that messages sent frorp one process to another process will be delivered to the destination process in the order in which they Vvere sent. However, since it is expected that NSW processes rn^y frequently desire message sequencing, it is possible for a process to ask NSG to sequence certain messages.

To achieve sequencing a process can specify when it sends a message that tha message is to be sequenced. MSG will guarantee that a sequenced message from process A to process B will be delivered tc process B only after all previous sequenced messages from process A have been delivered to process B. A process may. if it chooses, intermix sequenced and unsequenccd messages.

Several of the situations which motivate the presence of the alarm communication mode within MSG also require that a process receiving messages be able to distinguish messages sent before an alarm was sent (or received) from those messages sent afterwards. That is, it is often important for a pair >f processes to synchronize a message stream with respect to an alarm.

To facilitate such message-stream'alarm synchronization, MSG supports the concept of essage stream markers. A stream marker is an attribute of a message. When sending a message a process may specify whether or not the message is to carry a stream marker. MSG gua.'^ntees that a message M, sent from process A to process B, which carries a stream marker will be delivered to process B onlv after all messages sent by A prior to M have been delivered to B and before any messages sent after M by A. Furthermore, MSG will notify the receiving proceLS B whenever it delivers a message that carries a stream marker. The notification will be part of tho information normally supplied oy MSG to the receiving process.

When it is necessary to achieve message stream synchronization after an alarm, a pair of processes can use the MSG stream marker. This can be accomplished by pis mg a stream marker on the first message sent after the alarm ,was sent or received). Although stream marked messages are provided by MSG to simplify message-stream/alarm synchronization by MSG processes, it is important to note that MSG itself places no constraints upon how processes use stream marked messages.

Introduction 1-10

i mmaimm

nmimnMiiMn ..


1.7 Host Incarnations

The NSW is expected to provide continuous, ?4 hour a day, 7 day a week service. However, the various computer systems which support NSW processes nay not provide such continuous service. Proper NSW operation requires that MSG be able to deternine whether a name for a process refers to a process that MSG is currently manan-inp or to an obsolete one which MSG nanap-ed durinr a previous period of MSG service by the host computer system in question. (The term "incarnation" is used synonymously with "period of host MSG service" in the remainder of this document.) To enable MSG to distinpuish current from obsolete processes, an MSG process name (more precisely, a specific address) includes an indication of the host incarnation under which the process exists (or existed) .

Introduction 1-1 1

- ■

I1SG Jesi^n Specification 1/23/76

1.8 Organization of this Document

The remainder of this document specifies MSG ir. detail. There are four pares to the specification:

i. MSG process environment. Section 2 defines in detail the environment MSG provides to MSG processes. In particular, it defines the set of primitives that MSG provides to such processes.

ii. MSG-to-MSG protocol. NSW is a mul' -.-computer system. Parts of MSG will reside on the various computer systems that comprise the NSVI. The inter-computer protocol used by the compenents of MSG in order to support the MSG primitives is specified in Section 3-

iii. MSG-to-MSG Protocol for the ARPANET. The initial implementation of the NSW will make use of the ARPANET as an inter-computer communication medium. Section 4 specifies how the ARPANET host/host communication facilities are to be used to support ehe MSG-to-MSG protocol.

iv. MSG-to-MSG Transmission Formats for the ARPANET. Section 5 defines the formats to be used for the transmission of MSG-to-MSG protocol messages between ARPANET :iosts.

Introduction 1-12

r^ir-rr

,


2. MSG process anvironment

This section defines in detr,"il uhe environnent MSG provides to processes. This section covers chose aspects of the MSG process environment which are common to all hosts; it is not a process-implementer's ruide to MSG on any particular host, 'uch a puide must also discuss aspects of the process environnent which are peculiar to that host.

MSG process environment 2-1

-^w.

MSG Desipn Spec i fiorit ion 1/?3/76

2.1. Hosts

US cone host host sstl of t MSG run . NSW

oont not fail a ho

W is inplem(?nt urrently on a s . MSG on each 's operatinr s sfies the MSG he host enviro processes will

will operate inuously part scheduled for ed. We H »fine st incarnation

ed as a number of processes runninr njnber of different computer svstems, called liest can be thourht of as an extension of that

yscem, creating a new operating system that ciesign. Because MSG specifies onl> a fraction nnent for a process, it is renerally true that be sensitive to the type of host on which they

continuously, but individual hrsts may not be of it. This can occur because a riven host is continuous NSW service, or because the host has a particular period of NSl. service by a host as , designated by:

<host incarnation name> ::= <host desiprnatorXincarnat ion designators

where <host desip-nator> is an t^te^er which uniquely designates a particular host computer and <:' carnation desirnator> is an intep-er which desipnates this \ rticular period of NSW service by this host.


i ■■

Hmmmpm» mm>imm^,*im*,'»l'*„ ^--"- -'-'li-"-"' nWMHMMMI^wii

MSG Desip-n Specification 1/23/76

i 1 U

2.2. Processes

The form of an MSG process is stronply host-dependent, since the MSG design specifies only a part of the operating system under which the process runs. An MSG process is what one generally tninks of as a proc^ s, i.e. a collection of prop-rams, local memory, etc. to which the operating system allocates system resources such as CPU time. MSG processes must, however, have the

follovTiiiR properties: 1. The process can make at 1 "»ast some MSG primitive calls. 2. The process has a unique MSG process name throuph which

it can be addressed by other processes.

MSG process environmen 2-3

• •-- ^— — amsammmmmm lira- mi 1

MSG Desirn Specification 1/?3/76

.0 . 3 • Process names

A host incarnation supports a number of MSG processes. E^ch process has a name of the Torn

CDrocess liame> = <host incarnation nameXpeneric <iesi^nator> <spec.ific desirn a tor>

The host incarnation n-nne is the incarnation name of the under which the process is runninr. The peneric desipna character strinr which characterizes a process in terns functional relationship to other processes. This charact determines whether a process could be chosen to perform function. For example, processes with reneric desifTnatr

candidates for messapes which invoke Works Manaper funct rihe specific desipnator is an inteper. A process name is unambipuous; at all times it either corresponds to a sin process or is invalid.

host tor is a of its erization a certain ^ WM are ions. alv/ays

pie

MSG process environment

■ ivmrMiiii-i


2.M. Process addressing modes

There are two fundamental nc^es hy which one proces 3 nay address another process: generic and specific. A specific address is always a process name. Generally process A will use a specific address for process B because process A has had some prior communication with. B, either directly or throuph some intermediary process.

A generic address, however, is of the form:

<generic address> ::= <host desirnatorXrenerio designators j generic desipnator>

Unlike specific addressing, which uniqueiy determines the destination process, generic addressinp implies a selection by MSG of a destination process from a class of processes. This selection allocates the destination process to the communication implied by the r-enericaily addressed messare. This is dislinct from process allocation, in w'iich MSG creates and terminates processes.

The class of processes from which MSG can nick a destination process for a renerically addressed mossare is defined as follows: 1. If the reneric address is of form

<host desirrnatorX^eneric desirnator> then the process selected must be on the designated host. If <host desirnator> is not specified in the address, then the process may be on any host.

2. The <p-eneric designators field of the process name must match the <rreneric desipnator> field of the reneric address.

3. The process must have a Receivegeneric primitive call pendinr.


^jt


2.5. Modes of information transfer

MSG supports three basic nodes of information transfer between processes: nessares, alarms, and direct connections.

A message is a strinf of bits created in the local nenory of a sending process. MSG sends the messape to a receivinp process by duplicatinr the bit strinp in a specified portion of the receiving process's local memory. MSG itself imposes no further structure on nessapes, nor does it interpret the contents of messages. Messares are the only mode of communication which can be Fenerically addressed.

An alarm, like a messape, is a strinr of bits created by one process and addressed to another process. As with a messare, MSG transmits the bit strinr to the receiver process, which has designated beforehand where the bit strinr is LO be put. In other ways, however, alarms differ fron messapes. First, an alarm is a fixed-lenpth bit strinp and is shorter than most messages. Second, MSG will transnit an alarm independently of any messape traffic between sender and receiver processes. In fact, M3G will pive alarns priority service over nessapes. It is anticipated that alarns will be used to transnit in0orrnation about unusual or exceptional conditions, while messapes and direct connections will be used to support normal connun.'.cation.

A direct connection is a one- or tv/o-way dedicated channel between two processes. MSG assists the processes in oneninp and closinp the connection, but does not intervene in the actual use Df the channel.

Messapes are further differentiated by whether they are addressed to a specific process or to a generic class of processes. Processes use different primitive ^all0 uc .c. . ., and receive penerically-addressed nessares than Lne^ use to send and receive specifically-addressed nessapes.

For a specifically-addressed nessape it is further possible to specify either (but not both) of two types of special handlinp: sequencinp and strean markinp. Normally MSG will not ruarantee to deliver nessapes in the order in which they were sent. Sequenccd nessapes, however, fron orocess A to process D will be deliveied to B in they sane order in which they were sent by A. A strean narker nessape fron A to B will not be delivered to B until all other nessapes fron A to B nave been delivered. Furthermore, it will be delivered to B before any other nessapes to B sent subseouently by A.

MSG process environnent 2-6

——~' i ■■■rti


«

In all cases, MSG will inform the receivinr process of any special handling piven any message it receives.

tISG process environnent 2-7

intiiliftM-ii -


2.6. MSG primitive operations

Each host supports a set of MSG processes that run under it. The primitives will be host dependent sore tine later a reply (return) primitiv? calls into two CIPSSCS of the reply MSG makes to the pn primitive call the MSG reply s- n operation is complete. For the ot however, the MSG reply signifies were reasonable enough for MSG to perform and that MSG has agreed t operation. When this primitive op has been aborted, MSG will signal specified m the primitive call, primitive operation a pending eve is the completion or abortinp- of has the form:

primitive operations for the method of calling these

Every primitive call prcduces from MSG. We divide the set of differentiated by the meaning

mitive call. For one class of ifies that the primitive her class of primitive call, only that the parameters of call deduce what operation to

o attempt to perform this eration is finally complete or the process, using a signal

We call this uncompleted nt, where the event in question the operation. A pending event

<pendinF event> ::= <prinitive><signal><disp><timer>

where <primitive> is the primitive operation to be performed <signal> is a means by which MSG can signal the process

that the primitive operation is complete <disp> is a pointer to a field in the. process's local memory <timer> is a timer which tells MSG when it can abort the

operation.

Every host will offer processes a set of signals for u^e in primitive calls that produce pending events. We shall discuss signals at greater length later in this document. The disp field, which MSG will have set before it sends the signal, tells the process whether the primitive operation completed normally or was aborted.

The set of all pending events for a process is called that process's ^endinp" event set. l.'hen the process makes a primitive call of the second class, a pending event is added to its pending event set. When MSG completes or aborts a pendinp- event, it sets the appropriate disp field, sends the signal, and then deletes the pending event from that process's pending event set.

A process should ensure that no two elements simultaneously in its pendinr event set have the same signal, but MSG will not enforce this restriction. The simplest way for a process to ensure tnis is never to reuse a signal in a primitive call until


aa^-^ r if-rrtlMJiaMpahflu aifc «jfi i


that signal has been received from the old call. It should be emphasized that the signal for an operation is the only reliable way for a process to ensure that this operation has completed.


mm ^iniMM—i ■ -MWWÄidMM.

MSG Design Specification i/;:3/76

2.6.1 Primitives that create pendinr events

Many of the followinr pr.'i itives contain the paraneter dt. This is used to create the <timer> field of the pendinr event, and either specifies a timt interval in local hose clock units or indicates that a default value should be chosen by MSG. Unless the default is specified,

<timer> = tc+dt where tc is the local host clock tine when the primitive was called.

1 . Sendspecificmessare(ms^area,pnam,sifrnal,disp,dt »sphndl) where msgarf . points to a message to be sent pnam a process name sphnc specifies special handlinp for the messape 0 - ordinary handlinr 1 - sequenced ressare 2 - stream marker message

This causes the messape pointed to by ms/area to be sent to process pnam. At the ver> minimum, completion of this primitive operation means that the msrarea has been read by MSG, the disp field set, and the pendinr event deleted from the sender's pending event set. Local hosts may opt to guarantee more, such as that when the primitive is completed the foreign host has accepted the message.

2 . Sendgenericmessage {uicr.zrea , ^enadr , signal , disp , dt »pwait) where nsgarea points to a message to be sent frenadr is a generic address qwait is a boolean

This is like Sendspecificm,ssape except that here a generic address is specified instead of a nrocess name, there is no special handling, and there is the extra parameter qwait. Unlike a Sendspecificmessage, a GendgenericmessaFe may cause MSC to create a destination process. Qv/ait is a Doolean; setting it false will cause MSG to accept the primitive only if there is a process available with a Receivegeneric primitive pending.


M3G Desirn Specification 1/23/76

\. Reeeivespecificmessape(msRarea,srcnam,sipnai,disp,dt,sphrdl) where nsgarea points to a block of local memory in which MSG

will out a message srcnam points to a field of local memory which MSG will

set to the process name of the sender sphndl points to a field of local memory which MSG will

set to the special handlinp class of the messape beinp received:

0 ~ ordinary handling 1 - sequenced message 2 - stream marker messape

If the primitive completes normally, i.e. if the specified signal is received and the disp field does not indicate an error, then msparea will contain a messape which was sent by a Sendspecificmessape primitive call by some process. Srcnam will contain the name of the process that sent the messape, and sphndl will show if the messape was sequenced or was a stream marker.

4. Receivepenericmessape(msparea,srcnam,sipnal,di^p,dt) where msparea points to a block of local memory in which MSC will

put a messape srcnam noints to a field of local memory which MSG will

set to the process name of the sender

This is like Receivespecificmessape except that here the messape received was sent by a Sendpenericmessape primitive instead of a Sendspecificmessape primitive. There is also no special handlinp field.

MSG process environment 2-1 1

_j^


5. Sendalarm(acode,pnam,sippnal,disp) where acode is an alarm code pnam is a process name

This sends the alarm code acode to the process named pnam. When this primitive completes, the disp field will indicate one of the followinp; outcomes:

1. OK. Eithe'.1 the alarm was delivered to the process or it was queued and will be the next alarm to be delivered to the process.

2. Rejected. Process pnam is not accepting alarms at all now, or another alarm is already queued for this process, or sone error has occurred.

6. Enablealarm(acode,srcnam,signal,disp) where acode,srcnam point to fields of local memory

This enables the process to receive an alarm. When the alarm is received, acode will be set to the alarm code and srcnam will be set to the name of the alarm sender. In order for an alarm to be received, not only must an Enablealarm primitive be pendinp but also the iaccept boolean slate for this process must be true. This boolean value LS chanped by the primitive Aoceptalarms.



7. Ope-^connCconntype, conn id , pnan , sipnal, ciisp , dt) where conntype is a connection type TELETYPE BINARY SENr>-RECEIVE(s) BINARY SEND(s) BINARY RECEIVE(s) where s is a byte size ccnnid is a connection identifier pnan is a process name

This opens a connection of type conntype to process pnan. The connection will be identified by connid. In "der for the primitive to complete normally, process nnam must also execute an Openconn primitive addressed to this process, with the same connid and a compatible connLype. Some hosts may return a host-dependent identifier for the connection.

8. Closeconn (connid ,pnamfsiprnal ,disp ,dt) where connid is a connection identifier pnan is a process name

This refers to the connection created before by the primitive Openconn(conntype,connid,pnam,...). If the connection was never opened, Closeconn will abort with an error code in the disp field. If the corresponding Openconn is still pending, the Openc.nn also will abort. Whatever the outcome, however, when the Closeconn primitive completes, the connection, if it ever existed at all, will be closed.

9- Terminationsirmal(tsipnal,disp) where tsipmal is a signal

If this primitive ever completes, i.e. if tsipnal is ever received then it should be taken as a request by MSG for the process to terminate. The disp field may be used, at host option, to specify why the termination is beinp requested.


if «MirVy mi^^T. - . , ,mimm~ i*tMmm - n ■■■ ■" "

MSG D^sipn Specification 1/?3/76

2.6.2 Primitives that do not create pendinp events

1. Stopme()

This primitive indicates that the process wishes to terminate. Control will never return from this primitive. The process will be terminated by MSG as soon as possible. Well-behaved processes will ensure that their pendinp- event sets are empty before issuing this primitive.

2. Rescind(rsi^ral) where rsijprnal is a signal

This is used to delete a pendinr primitive operation. Tie parameter rsipnal must be the signal of a pendinp event, i.e. an uncompleted primitive operation. If the Rescind call returns successfully then the correspondinp primitive will not occur and rsignal will not be sent. The Rescind may fail because the primitive operation is partially complete and it is too late to stop it, or because rsjfndi no longer corresponds to a pendinr event. The latter case generally means that the correspondinp primitive has already completed. It is a host option what primitives may be rescinded at all.

Some hosts may wish to return an event handle with rescindable primitive calls. In this case, the call will he Rescind(event handle).

3- Acceptalarms(aaccept)

Each process has a boolean state value, iaccept. If an alarm is sent to a proces^ whose iaccept state is false, the Sendalarm will fail with a disposition indicating that thc- process is not accepting alarms. If, however, iaccept is true then the Sendalarm will either match an Enablealarm, be queued, or be rejected because another alarm is already queued for this process. Acceptalarms sets iaccept to the value of qajcept.

4. Resynch(pnam)

If MSG had been rejectinr sequenced messages to process pnam due to failure of a sequenced message transmission, then HSG will now stop d o 1 n r so.


rliüiriHif ii ,. MiMtm


2.7. Signals

Each host provides for processes running under it a set of signals. A signal is a means by which MSG can inform a process that some event has occurred, in particular that MSG has completed some primitive operation.

Different hosts will offer different signals, but all signals must satisfy certain criteria:

1. At any point in time, the process can determine whether or not the signal has been received.

2. Signals must be distinguishable, i.e. if one of several possible signals has been received, the process must be able to determine which one.

3. Signals are local. A signal to one process does not directly affect any other process.

The restrictions listed above allow variety of signals for processes. It i section to further specify what sipnal host. We list here some examples of si provide. These are strictly examples; requirement that these particular sign 1. Block/Unblock

The process waits and control does primitive call until the event has

2. Flag MSG sets a field in the process's when the event has occurred. This <disposition> field itself.

3. TENEX PSI on channel n On TENEX, MSG send? an interrupt o event has occurred.

4. Flag plus TENEX PSI MSG sets a field in the process 's then sends an interrupt on ?n agre which is the same for all signals differs from example 3 in that her cause interrupts on the sane cnann queues PSIs on a channel only one PSIs nay be lost if MSG sends seve type sufficiently close to each ot care, a process can handle the res undue dlfflcultv.

hosts to specify a wide s not the function of this s will be available on any gnals that a host might they imply no MSG als be supported:

rot return from the occurred.

local memory nonzero field could be the

n PSI channel n when the

local memory nonzero, ed-upon PSI channel of this type. This e different signals el. Because TENEX interrupt deep, some ral signals of this her in time. With ulting race without

MSG process environment

2-15


2.3 Information transnittal

The sendinp; of messages and alarms and the openinp and clo.sinr of connections all involve a pairinp of compatible primitive operations in the pending event sets of (usually) different processes. Such a pairing defines an interchanpe of information between two processes which MSG must cause to happen. Tne possible pairinps are:

1. Specifically-addressed message This pairs the primitives Sendspecificmessapre(ma,pb,...) in process pa Receivespecificmessape(mb,snam,... ) in process pb

This causes the message pointed to by ma to be transmitted by MSG to process pb and put into the memory area pointed to by mb. In addition, snam in process pb will b^ set to pa so that the receiving process will know the name of the sendinr process .

2. Alarm This pairs the primitives Sendalarm(acode , ^b , ... ) in process oa Enablealarm( cdval snam,...) \r\ process pb

This pairinrr is possible only if the boolean state variable iaccept in process pb is true. This causes the alarm code acode to be transmitted f^om process pa to process ob and put into field cdval. In addition snam will be set to pa, the name of the sendinp- process.

3. Generically-addressed messape This pairs the primitives Sendpeneriernessape (ma , crenadr , . Receivesenericmessa.re(mb,snam,

. ) in process pa

..) in process pb

This is like a specifically-addressed message pairinr except that here penadr is a re.-^^ic address which matches process name pb instead of beinr pb directly.

MSG process environment 2 .16

-in

1/23/76

) in process pa ) in process pb

MSG Desipn Specification

4. Openinp- a connection This pairs the primitives Openconn(ta,connida,pb,. Openconn(tb,connidb,pa, .

where connida = connidb L^ and tb are compatible connection types: 1. ta - tb = TELETYPE 2. ta = tb = BINARY SEND-RECEIVE(s) 3. ta = BINARY SEND(s)

tb = BINARY RECEIVE(s) where s is a byte size.

This opens a connection of the indicated type between processes pa and pb. The connection will be hereafter identified to both processes as connida (= connidb).

5. Closing a connection This pairs the primitives Closeconn(connid,pb,...) in process pa Closeconn(connid,pa,...) in process pb

This will close for both processes the connection between them which is identified by connid.

These pairinrs define tasks that MSG is to perform, but they allow MSG hosts a rreat deal of freedom in schedulinr computer time and resources to the muluitude of concurrent operations they must perform. We must, however, specify a few more rules:

1. Fairness. MSG will not prossly favor any one process, mode of communication, or particular operation over any other. Exceptions are: a. Alarms will be favored over messages. b. Transmission of messapes with special handling

attributes may be delayed until other related messages have been transmitted.

2. Access to communication. A process must always be able to have in its pendinp event set: a. One messape send primitive. b. One messape receive primitiv,. c. One alarm send primitive. d. One alarm enable primitive. e. One primili*. e to open or close a connection.

3- Efficiency. Within limits set by the above rules, MSG will amnpe its workload so as to perform it in a ^easo^.ably efficient manner.


-■^v .X. •" -— - ■ ■■■^-^' " 1 fll -——-

MSG Desiftn Specification 1/23/76

2.9 Sequencing of niessapres

As that a c process in which messages communic insure p expected it is po messaRes

noted in Section 1.6, MSG normally does not guarantee ollection of messages sent from me process to another will be delivered to the destination process in th.- order they were sent. Some applications will require that the between two processes be sequenced. In such cases, the

ating processes could observe a private protocol to roper sequencing of messages. However, since it is that processes ..u. ^ frequently desire message sequencing,

ssible for a process to ask MSG to sequence certain

To achieve sequencing a process can specify when it sends a message that the message is to be sequenced. MSG will guarantee that a sequenced message from process A to process B will be delivered to process B only after all previous sequenced messages from process A have been delivered to process B. A process may, if it chooses, intermix sequenced and unsequenced messap-es.

The sending and receiving discir1ines required of MSG to support sequenced messages are discussed below. Processes should be aware that a cost is associated with the use of the message sequencing option; that cost will be reduced message throughput.

MSG cannot guarantee that every message will be delivered. (The destination host may be temporarily inaccessible, the destination process may spontaneously disappear, the message nay be timed out, etc.) When MSG is unable to deliver a normal, unsequenced message, the sending process is signalled and notified (via the disposition information normally supplied by MSG) that the message could not be delivered. The sending process can then take whatever action it feels is appropriate with respect to the message in question.

s eq since a seq ue the s e q u e n o e . that proces «5 messages Ml i

success full y should MSG do to deliver M2 to deliver th M3, Mh and M5 3 are cor.muni sequencing i .;- deliver the r

uencing introduces an additional comple need message is not independent of cthe

To illustrate the nature of the probl A has attempted to send process B the s M2, M3, M4, M5. Furthermore, suppose t delivers Ml but is unable to deliver M2 with M3, M^, and M5? In particular, i does not necessarily mean that MSG wil

e remaining messages in the sequence. without M2 may confuse process B; pro eating via sequenced messages presumabl important. Therefore, MSG will not at

emaining pendln; sequenced messages.

xity here r messages in em, suppose ecuenced hat MSG . What ts inability 1 be unable Delivery of cesses A and

y because tempt to


..'»■v^./^-«.-„f ..,,-,-


If MSG cannot deliver a sequenced message from process A to process B, it will stop the flow of seqjenced nessa^es to process B from process A until process A takes some explicit action to "resynchronize" the message sequence. MSG does this by marking process A as beinp out of synchrony with process B after a sequenced messape from process A to process B fails. MSG will then abort all pending sequenced Sendspecificmessage primitives m process A's pendinp event set which are addressed to pr jess B. Furthermore it will reject all such primitive calls subsequently made hy A until A r0synchronizes the message sequence with B by executing the primitive Resynch(B).

As noted ir Section 1.6, in situations in which an alarm is transmitted or received, it is often important for a pair of pr )cesses to identify a point in a stream of messages between them corresponding to "where" the transmission (or receipt) of the alarm occurred. To facilitate such message/alarm synchronization, MSG supports the concept of message stream markers. A stream marker is an attribute of a message. When a process sends a message it can specify whether or not the message is to carry a stream marker. The default is no stream marker.

MSG guarantees process B, which car process B only after delivered to B (or h undeliverable) and b Furthermore, MSG wil delivers a message t notification will be MSG t the receivinr places no constraint However, we expect t adopted for NSW.

that a message M. sent from process A to ries a stream marker will be delivered to all messages sent by A prior to M have been

ave been determined by MSG to be efore any messages sent after M by A. 1 notify the receiving process 3 whenever it hat carries a stream marker. The part of the information normally supplied by process. We emphasize that MSG itself

s upon how processes use stream markers, hat standards repardinp their use will be

MSG observes a oueuinp discipline with respect to Receivespecificmessage primitives. The Receivespecificnessape primitives executed by 3 process are to be satisfied in the order in which they art-, issued in the sense that the first Receivespecificmessage should be satisfied by the first message MSG accepts for tne process, the second by the second message, etc. We note that this does not necessarily imply that the signals associated with a collection of pending receives will be delivered to the receiving process in the order in which the receives were satisfied.


^^_ ----- -

MSG Design Speolfication 1/23/76

In additio not imply that delivered in th If in-order del request "sequen for a message i discipline wher receivinp MSG h the sending pro stream marking observes a send only after the from sender to messages from s this message. receiving disci is sufficient t marked messages

n, we note that this MSG receiving discipline does messages from a given sending process will be e order in which the sending pro^oss sent ^hem. ivery is required, the sending process must ced" or "stream marker" handling. When sequencing s requested, the sending MSG observer ^ sending eby it transmits the message only after the as accepted all previous sequenced messages (from cess to the receiving process). Similarly, when for a message is requested, the sending MSG ing discipline whereby it transmits the message receiving MSG has accepted all previous messages receiver and additionally transmits no further ender to receiver until the receiving MSG accepts These sending disciplines, together with the pline described above and always followed by MSGs, o insure in-order delivery of sequenced and stream


»ic-rnutfrf^ n

MSG Design Specification 1/23/' 6

2,10. Process creation and termination

To create a process MSG performs the followinp: operations: 1. MSG assigns a process name to the process and creates

an empty pending event aet for it. 2. MSG creates the {.^ocess on the host operatinp system. 3. MSG starts the process in some host-dependent apreed-upon

initial state.

An MSG host may create processes for one of only two reasons: 1. In order to fulfill its oblipation to find a destination for

a penerically addressed message. 2. As part of system initialization or restart.

To terminate a process, MSG performs the following operations: 1. MSG marks the process for termination in such a way that

it will no longer be a candidate for any communication from other processes and such that it is blocked from issuing any more MSG primitives.

2. MSG completes or rescinds all elements in the process's pending event set.

3- MSG deletes the process from the host. 4. MSG forgets about the process.

flSG process environment 2-21

_.-

rtSG Desipn Specification 1/23/76

2.11 Summary of terms We present here a brief summary of the terms defined in

this section: 1. Host incarnation name

<host incarnation name> ::= <host desifrnatorXincarnation desipnator>

2. Process name <process name> : : = <host incarnation nameXp-eneric designatorXspecific designator)

3 . Generic addt ess <generic address: ::= <host desi^natorXpeneric desip-nator> I

<Generic designator)

4. Generic designator <peneric designator/ ::- character strinp

5. Specific oesignatcr <specific designator) ::~ integer

6. Host designator <host designator) ::- integer

7. Incarnation designator <inca'"nation desik.iator) ::= integer

M3G process environment 2-22

.

r. MSG Desipn Specification 1/23/76

3. MSr lu-MSG Protocol

This section specifies the Inter-hcst MSG protocol which supports the primitives provided to processes nanaped by MSG. The concern in this section is the information communicated between MSGs rather' tnan how it is communicated. This section assumes the existence or a bi-directional communication path between each pair of MSG nost systems. Issues such as how these MSG-to-MSG oaths are supported by ARPANET communication capabilities or how MSG-to-MSG messages are delivered are the subjects of Sections 4 and 5.

MSG-to-MSG Protocol 3-1

i*»iirra«¥i 11


3.1. Transaction Identifiers.

The completion of an inter-host MSG transaction (such as the transmission of a messape or an alarm) generally requires a protocol exchange that involves several inter-MSG messapes. When an MSG initiates an inter-host transaction on behalf of a process it manages, it generates an identifier for the transaction whict it places into the inter-MSG message which initiates the transaction. In addition, the initiating MSG generally places the name of the initiating process into the inter-MSG message.

When an MSG responds to an inter-MSG message that initiates a transaction, the responding MSG includes the transaction identifier chosen by the initiating MSG in its response. If the transaction in question is one that requires further interaction between the MSGs, the responding MSG generates a second identifier (its identifier) for the transaction and places it into the respcnoe message. All subsequent inter-MSG messages which refer to the transaction will include both transaction identifiers .



3.2. On the use of "source" and "destination".

Most inter-MSG messages are transmit interactions between a pair of processes, these messages include the names of two p two transaction identifiers. in the spec we adopt the convention of using "source" process or transaction identifier managed and "destination" when referring to a pro identifier managed by the responding MSG. relative to the initiator of the transact to the sender of a particular message in messages needed to carry out the transact

ted to support Consequently, most of

rocess and many include ification that follows, when referring to a by the initiating MSG

cess or transaction "Source" is then

ion; it is not relative the series of protocol ion.

MSr-to-MSG Protocol 3-3

JST ii i ii ii uai ^Mit — -—mi


3.3. MJG-to-MSG Protocol Items.

In the specifications of inter-host MSG protocol items that follow, the items are grouped according to the primitives they support. In these specifications all information exchanged between MSGs is explicitly represented as parameters of the various protocol messages. In some cases some parameters may be implicit from the protocol exchange context and are therefore redundant. Section 5 defines the transmission formats for the protocol items in detail.

1. MSG-to-MSG protocol for interprocess messages (SendSpecificMessage, ReceiveSpecificMessage , SendGenericMessage, ReceiveGenericMessage)

MESS (source-process, destination-process, source-ID, destination-ID, handling, length, message-data)

This initiates an inter-MSG message transaction. It indicates that the source-process has requested that a message (defined by length, message-data) be delivered to the destination-process. The source ID is the idrntifier selected by the source MSG to identify the message transaction. The destination MSG should include source-ID in all communication concerning this message transaction. The destination-ID is empty if it is unknown; it tak:s on meaning for Interactions requiring more than a simple request and acknowledgement (see descriptions of MESS-HOLD, HOLD-OK, MESS-CANCEL and XMIT below). The destination-ID is an identifier selected by the destination MSG for the message transaction. The handling parameter specifies the special handling (if any) required by the receivxü,- MSG in order to properly deliver the message. Examples of special handling include: include a synchronization marker with message; MESS-HOLD not an acceptable response (see below); MESS-HOLD acceptable and this MESS is an implicit HOLD-OK (see below).

Protocol requires the destination MSG to promptly acknowledge MESS with one of the following three messages.

MESS-OK (source-process, destination-process, source-ID)

This response to MESS indicates that the destination MSG takes full responsibility for buffering the message data and subsequent delivery of the data to the destination-process. This reply implies that destination-process is currently a valid name.

MSG-to-MSG Protocol 3-^

,*m*MälJ~m~^rT'm 1 iir Tifc«Mii^MiBiifciMn 1 1 ir... ■.^^—^--


It does not imply that the message data has been actually received by destination-process, nor does it guarantee that destination-process will ever accept the data.

MESS-REJECT (source-process, destination-process, source-ID, reason)

This response to MESS indicates that the destination MSG will not accept the request for the transaction identified by source-ID. Reason indicates the reason for rejection. Possible reasons include: no such process, no buffer space, too many messages already queued for this process, etc. The reason supplied might be one which attempts to stimulate retransmission by the source MSG if the rejection is known to be of a temporary nature.

The following fcur MSG-MSG protocol items provide an important extension to the basic message transmission discipline of MESS, MESS-ÜK, and MESS-REJ described above. These additional protocol items are motivated by the need for flexible flow control within MSG. Their inclusion introduces complexity to the protocol. However, the flexible flow control they support is sufficiently important to iustify this complexity.

MESS-HOLD (source-prcoess, destination-process, source-ID, destination-'.D)

This response to MESS indicates that the destination MSG will not accept the inessage data associated with the specified message transaction but that it will remember that the message transaction has been requested and at some time in the future will ask the initiating MSG to retransmit the message data. The destination-ID is the identifier selected by the destination MSG for the message transaction. Both source-ID and destination-ID should be included in any subsequent MSG-to-MSG communication concerning this message tran1 «action.

Protocol requires that the source MSG acknowledge the MESS-HOLD promptly with one of the following two messages.


—.., . —


HOLD-OK (source-process, destinatio.i-process, source-ID, destinalion-ID)

This reply to MESS-HOLD indicates that the source MSG agrees to buffer the message associated with the transaction specxfied by source-ID and destination-ID. The destination MSG will remember the pending message transaction and request transmission of the message when it is able to accept the message data.

MESS-CANCEL (source-process, destination-process, source-ID, destination-ID, reason)

This reply to MESS-HOLD Indicates that the source MSG is unwilling to buffer the specified message. In addition, it may be used by a source MSG to indicate that it has ceased buffering a message which it had previously agreed to buffer.

XMIT (source-process, destination-process, source-ID, destination-ID)

This is used by a destination MSG Do request a source MSG to transmit a message previously buffered. The XMIT signals that tie message will, in all probability, be successfully accepted. On receiving a XMIT, the source MSG is expected to transmit the message identified via a MESS message (usinp the specified source-ID and destination ID to identify the transaction in question). All legal responses to a MESS request are appropriate for the redelivery.

A destination MSG can send a MESS-REJ rather than an XMIT in order to abort a message transaction for which the message is buffered at the source. It might choose to do this if the destination-process termi .jates without requesting the message.

We note that since a destination MSG can utilize the MESS-HOLD option, it may be important to provide processes managed by MSG means to declare that a MESS request be accepted or rejected immediately (i.e. not held) by a destination MSG. This concept is not currently supported at the process-MSG interface level; should it become important to do so, the "handling" oarameter of the ME^S item will be used to support the concept at the inter-MSG protocol level .


"-'■m--T -— -*****-.-. - - ■ -i^-^- -- - . -,


2. MSG-to-MSG Protocol for4 Interprocess Alarms (SendAlarm, EnableAlarm)

ALARM (source-process, destination-process, source-ID, alarm-code)

This initiates an inter-MSG alarm transaction. It indicates that the source-process has requested that an alarm be transmitted to the destination-process. A few bytes of data (alarm-code) are to be conveyed to the destination-process alonf^ with the alarm. The ALARM message should bypass the flow control mechanism applied to normal interprocess message transactions (MESS). Source-ID is the identifier selectee by the source MSG to identify this transaction.

Protocol requires that one of the following two messages be sent promptly to acknowledge the ALARM,

ALARM-OK (source-process, destination-process, source-ID)

This response to an ALARM request indicates that the alarm request has been accepted by the destination MSG. It does not mean that the alarm has been received by the destination-process; it may be the case that the alarm is never actually delivered to the destination-process.

ALARM-REJECT (source-process, destination-process, source-ID, reason )

This resoonse to an ALARM request indicates that the destination MSG refuses to accept the al^rm. Reason indicates the reason for rejection (e.g. incorrect destination process name, process not acceptinp alarms, another alarm is already queued , etc ) .


-i n iiaMM^^^ä^^.^^-^-^^^^.. .^^ __ ■-—w ^M^M_X: ^_J_______


3- MSG-to-MSG Protocol for Direct Access Communication (Openconn, Closeconn)

Because of the symmetric nature of the following three protocol messages, we change our conventions with respect to "source" and "destination". In the description of these three items, "source process" always indicates ehe process local to the sending MSG and "destination process" always indicates the process at the receiving MSG. The same convention is used for the transaction ID fields.

C0NNECT10N-0DEK (source-process, destination-process,source-ID, destination-ID, user-connection-ID, type, source-socket)

This message indicates that the source process desires to establish a direct communication path to the destination-process of the "type" specified. The source-ID is the identifier selected by the source MSG to identify the operations concerned with establishing and breaking the connectionis) . Destination-ID is rmpty when unknown.

[For implementations which make use of the ARPANET, the source-socket specifies the socket(s) at the source MSG host which is (are) to be used in establishing the connection which implements the communication path. Protocol states that the ARPANET RFCs required to establish the connect ion(s) are to be exchanged immediately after both source and destination MSGs have agreed to the connection (by exchanging matching CONNECTION-OPEN messages).J

CONNECTION-CLOSE (source-process, destination-process, source-ID, destina on-ID, reason)

This protocol message indicates that the sending MSG wants to close the connection identified by source-ID and destination--D. Protocol specifies that the receiver shoulr, close the crnnecuion and acknowledre the request with a matching CONNECTION-CLOSE. CONNECTION-CLOSE may be sent to abort a connection which has not yet been completely opened. Reason indicates the reason the connection is being closed. Possible reasons include: orocess requested close, byte size mismatch, type mismatch, and entry timeout.


Li

MSG DesiRn Specification 1/23/76

CONNECTION-REJECT (source-procesc, destination-process, destinat?on-ID, reason)

This item is used to reject a CONNECTION-OPEN or a CONNECTION-CLOSE request. It does not require an acknowledgement. Reason indicates the reason for rejection Possible reasons include: no such destination; no such connection. The transaction identifier returned is the "source-ID" for the request being rejected.

4. MSG-to-MSG Protocol for Obtaining Process Status (Get-status primitive)

An MSG primitive to be used to obtain information regarding status of an MSG process is to be sper^fied in the future.

The "get-status" primitive will not be required in the firsc MSC implementation. The following describes, in general terms, thr(

the si MSG ^ee

protocol items which are intended to support the "get-status" primitive.

SEND-STATUS (source-process, destination-process, source-ID)

This protocol message requests the status of the destination-process on behalf of the source-process. Source-ID is the identifier selected by the source MSG for the ctatus transaction.

Protocol requires that one of the following two messages be promptly sent in acknowledgement of SEND-STATUS.

STATUS-OK (source-process, destination-process, source-ID, status-words)

This returns the status information requested by the source MSG. The information to be included in the status report has not yet been completely specified. We expect that it will include the state of destination-process including pending Sends and Receives as well as pendinp: alarms.

[Note: it may not be desirable to allow a process LO obtain detailed status information about processes with which it is not actively communicating. The precise access controls (if any) that are required for the Get-status primitive will be defined in the future. ]


. -, —I.**

MSG Dtsip:n Specification 1/23/76

STATUS-REJECT (source-process, destiiation-process, source-ID, reason)

This response is used to indicate the rejection of a SEND-STATUS probe reouast. Reason indicates the reason for the rejection.

5. Miscellaneous 'iSG-to-MSG Messages.

The following MSG to MSG messages are provided because they have proven useful in comunication system implementations and for experimental extensibility.

NOP

This message is a no-operatxon. ic has no effect and is immedi^cely discarded by the receiving MSG. No reply is required.

ECHO (data-byte)

This protocol message requests the receiving MSG to echo the data-byte. It can be used to see if a remote MSG is actively functioning. Protocol specifies that the data-byte of an ECHO message be promptly returned tu the sending MSG in a matching ECHO-REPLY message.

ECHO-REPLY (data-byte)

Reply to ECHO.

EXPERIMENTAL (command, length, data)

This messaRe provides for experimentation ami extensibility within the MSG-to-MSG protocol. The com^rind specifies the function reauested; the length specifies the number of bytes in the EXPERIMENTAL protocol message; data is information relative to the function requested.



4, MSG-to-MSG Protocol for the ARPANET

k

i

4.1 Implementation of MSG-to-MSG paths by ARPANET connections.

Section 3 introduced the notion of "MSG-to-MSG paths" across which ".iter-host MSG messrv,es are sent. A single such MSG-to-MSG path exists between each pair of host MSGs.

MSG-to-MSG paths are virtual entities in the sense that they are implemented by ARPANET host/host protocol conne tions. At any given time, a given MSG-to-MSG path may be implemented by zero, one or more pairs of ARPANET host/ho^t connections. The standard byte size for ARPANET connection which implement MSG-to-MSG paths is 8 bits.

The set of ARPANET connections which implement an MSG-to-MSG path are equivalent in the sense that any legal inter-host MSG message can be sent over ary one of the ARPANET connections in the set.

To send a message to another MSG, an MSG selects one ARPANET connection from the set that implements the MSG-to-MSG path and transmits the message over the connection. If no such ARPANET connection exists, the sending MSG must act to establish one.

MSG-to-MSG Protocol for the ARPANET 4-1

^— —'—iiffir ... -^ r.^. -^ T^ rr. _ _


1.2 Establishing the ARPANET connections.

A pair of ARPANET connections which supports an MSG- to -MSG path is established via an TCP to a "well known" contact socket in the normal way. The contact socket for MSG is 27 (decimal) - 33 (octal).

After a new pair of connections is established by an ICP, the pair of MSGs mast engage in a synchronization exchange before they can use the connections to carry the inter-MSG messages defined in Section 3. The purnose of this MSG-MSG synchronization is to allow the two MSGs to exchange their current ^incarnation,, numbers and any other information pertinent to subsequent interaction via the connection pair.

An MSG incarnation number« ident ^ies a particular period of MSG service. (We frequently use the ^m ''MSG incarnation" to mean such a period of MSG service.) A period of M3G service ends and a new period of MSG service begins when an MSG re-initializes itself. This typically occurs after its hort has restarted or th-? MSG itself has crashed aid been restarted. An MSG is expected to know its current incarnation number and to change its incarnation number when a new period of service begins. (An MSG could Jo this by storinrr its incarr.ation number in a file which is prenerveJ over host and MSG crashes. When a new period of service begin^. the MSG could increment the stored incarnation number . nd use the number obtained to identify the new period of service. )

At: now.ed in Sections 1 and 2, MSG process names include an incarnation number component which serves to identify the incarnation of the MSG that generated the process name and is responsible for managing the process. The MSG incarnation number component of a process name is used to determine whether the process named is one that currently exists or is an obsolete one which was managed by the MSG d ring one of its previous periods of service.

The MSG-to-MSG protocol for the synchronization exchange is:

1. The MSG that initiated the ICP initiates the synchronization exchange by using the send connection of the pair to send the message:

SYNCH (my~incarnation, your-incarnation, ve-sion, data)

where:

MSG-to-nSG Prctcc-l for the ARPANET 4-2


my-incarnacion identifies tho current incarnation of the initiating MSG.

your-incarnation is empty, version identifies the version of the MSG-to-MSG

protocol to be used on this connection, data is other synchronization information.

(To be defined in the future.)

2. The other MSG responds tc the SYNCH hy usinp the send cciinection of the pair to send the messape:

SYNCH (rny-incarnat ion , your- incarnation , version, data)

where: my-inc^rrr*tion identifies the current incarnation

of the respondinp MSG. version identifies the version of uhe MSG-to-MSG

protocol to be used on this connected, your-incarnation echoes the incarnation number

specified in the mitiatinp MSG's SYNCH message.

data is other synchronization information.

After the synchronization exchanre is completed, the connections may be used to carry any of the inter-MSG messapes defined in Section 3 until the connections are closed (see Section 4.3 below).

An MSG may wish to ascertain that the entity at the other end of i new connection pair is indeed another MSG before it commits any of its host resources to actinr uoon protocol messapes received over the new connection. Section ^. 4 below defines a procedure which MSGs may use to reliably authenticate one another.

MSG-to-MSG Protocol for the ARPANET a-3

-r-' ■wtiitiMirii ■ nimii a^a—aaMMMMM TilM»! ___ ,


4.3 Breaking the ARPANET Connections.

A pair nf ARPANET conneccions to another host represents a resource which an MSG may not want to keep open indefinitely in the absence of MSG traffic. If an MSG were to close a connection pair unilaterally, messages in transit from a remote MSG could be lost or garbled. A protocol mechanism is defined for closing pairs of connections in an orderly manner that eliminates the possibi1ity of such lost or garbled messages.

T e protocol for closing a pair of connections is:

1 . MSG sends an MSG-to-MSG "CLOSE" message over the send connection of the pair that is to be closed and then closes the send connection of the pair;

2. Upon receipt of an MSG-to-MSG CLOSE message an MSG is expected to: close the connection which carried the message; return a CLOSE message on the send connection of the pai .' (when it is convenient to do so); and close the send connection.

The orotocol exchange defined above is the mechanism for breaking pairs of connections. At present, we refrain from specifying in detail a policy which defines when MSG may use this mechanism.

An MSG that does not wish to communicate with the entity that has initiated an ICP should respor. . to the initiator's SYNCH message by initiating the CLOSE protocol exchange. An MSG might choose to do this if the syncnronization data supplied by the initiating MSG is incompatible or "if the initiating entity can not properly be authenticated as another MSG.

MSG-to-MSG Protocol for the ARPANET

^.^ — ■- - ■ ■■ .^-^^s^^-..-. ^^^

MSG Design Speci 'it ion 1/23/76

k,*\ Authentication of MSGs.

As noted in Section 4.2 above, it nay be important for an MSG to be able to reliably authenticate the entity at the remote end of a pair of ARPANET connections as another MSu before host resources are committed to requests made by that entity. The problem here is one of mutual authentication. Kach entity must authenticate the other as an MSG.

[In the absence of an authentication procedure, there is no way for an MSG to determine whether the entity at the remote end of a connection is another MSG or a bogus process which follows the MSG-to-MSG protocol. Failure to distinguish between an MSG and a process masquerading as an MSG could result in the inadvertent disclosure o/ private information or unaccountable use of expensive resources.]

The use of passwords is one approach to MSG authentication. Only an MSG would know the password and thus be able to properly identify itself to another MSG. We reject the password nechanism as unreliable and operationally impractical for the following reasons:

1. Use of a password requires that the password be stored in the sending program or be accessible to it in some way thereby increasing the likelihood that the privacy of the password will be compromised.

2. If a password is compromised, it must be changeo at both sending and receiving hosts; this represents a synchronization problem.

3- Truly secure authentication would probably require passwords for each pair of hosts; this would require N^N passwords for an N host NSW.

The mechanisms to be us^d for MSG authentication are based upon the properties of ARPANhT host/host communication. First, we assume that the TCP is a secure procedure. That is, we assume that a host can guarantee that i-iSG is the only entity that has access zo the MSG ICP contact socket and that MSG is the only entity that has access to the connections resulting from the ICP. This is the standard assumption made in the ARPANET regarding the ICP. Thus, the authenticity of the entity responding to an MSG ICP as an MSG is based upon the security of the ICP procedure.

The authentication problem that remains is that of authenticating the entity that initiates the ICP. Thi

MSG-to-MSG hrotocol for the ARPANET 4-S

*«--


authentication can be achieved in a manner similar t ICP responder. Just as a sinple well known ICP cont defined, a collection of well known "ICP-from" socke sockets from which ICPs are initiated) could be defi collection of ICP-from sockets are required due to t the ICP which prevents reuse of the ICP-from socket connections resulting from the ICP are discarded.) be required to limit access to the ICP-from sockets connections that result from the ICP) to MSG Just as required to limit access to the ICP contact socket ( connections that result from the ICP). If this were an MSG responding to an ICP could authenticate the i entity as an MSG by checking that the socket from wh was initiated was one of the well known ICP-from soc

o that of the act socket is ts (i.e., ned. (A he nature of until the A host would (ard the it is

and the to be done,

nitiating ich the ICP kets .

Some hosts find it inconvenient to limit access to a collection of sockets but have no difficulty in controlling access to a connection once it is established. Therefore, a variation of the above approach is used for authenticating initiating MSGs. A single send socket is defined for MSG authentication; access to the MSG puthentication socket is limited to MSG. The authentication socket is to be maintained by MSG in a listening state. In re^nonse to an RFC for the authentication socket, MSG should open the requested connection 'with byte size = 32) and send a specification of the sockets hich it is currently using in active MSG-to-MSG connections. ihe connection should then be closed and the authentication socket returned to the listening state.

An MSG at host A responding to an ICP initiated by a remote entity at host B can authenticate that entity by the following simple procedure:

1. The MSG at A notes the remote sockets, SI and 32, used in the connections that result from the ICP.

2. It opens a connection to the authentication socket at B, reads the socket specification that the MSG at B send: and closes the authentication connection.

3 If the remote sockets, SI and 32, are included in the specification then the entity at B is an MSG; otherwise, it is not. (Note that when the MSG at B initiates an ICP to the MSG at A, it must remember the sockets it uses so that it can include them in the socket specification sent to the MSG at A.)


MSG Desipn Specification 1/23/76

The reliability o upon the ability of ho the authentication soc specification sent ove exactly what host B mu well known contact soc MSG at A have means to remote end of connecti information NCPs must connection. Thus, the at A. The authenticit trustworthiness of the if they were not, then between ARPANET hosts.

f Uiis a st B to ket and r the au st do to kets. ) reliabl

ons. So exchange socket

y of the NCP at

e could

uthentication procedure depends insure that only MSG has access to to the sockets named in the thentication connection. (This is insure the security of ICPs to its

In addition, it requires that the y determine sockets in use at the cket identity is part of the in order to open a host/host

information is available to the NCP information depends upon the

B. We assume NCPs to be secure; be no reliably securo communication

Tne MSG authentication socket is 29 (decimaly = 3? (octal). The specification of MSG sockets returned over the authentication connection may be a ranpe of sockets or a ]ist of sockets. A socket range is transmitted as 3 bytes:

byte 1 : 0 indicates ^anpe spec byte 2: Sa byte 3: 3b

All sockets within the range defined by Sa and Sb (including Sa and Sb) art; MSG sockets. A list of N sockets is transmited as N+2 bytes:

byte 1: 1 indicates list spec byte 2: N the number of bytes that follow byte 3: SI byte 4: S2

byte N+2: SN

The MSG sockets are 51, S2, SM


for the ARPANET

WMmsr.

NiSG Design Specification 1/23/76

4.5 Error Control for M.^u-to-MSG Paths

ARPANET t.ost to host communication is reasonably reliable. However, communication failures can occur. For example, host/host messages are lost occasionally. A lost host/host message may manifest itself at the MSG-to-MSG path level as a "hung" connection (if the message lost was a host/host allocate) or cs a totally or partially lost MSG-to-MSG message (if the message lost was a host/host data message).

In addition, communication between a pair of hosts can be interrupted temporarily. The interruption may be the result of a transient network failure (e.g., the source or destination IMP crashes and is restarted) or a transient host service interruption (e.g., TENEX hosts occasionally experience BUGCHK interruptions and resumptions). At the MSG-to-MSG level this may manifest itself as a spontaneously closed host/hosu connection. If the connection was being used at the time, this could result in a lost or garbled MSG-to-MSG message.

Mechanisms to insure reliable communication in an environment where messages can be lost are reasonably well understood. These mechanisms typically require positive acknowledgement cf all messages and the use of a 4: ime out and retransmission scheme. This generally requires that the communicating entities (in this case pairs of MSGs) use unique identifiers or sequence numbers to identify messages in transit and employ techniques for detectinp; duplicate m^ssares (the message may have made it but its acknowledgement may have been lost). Note that these message identifiers serve to identify individual inter-MSG messages and are therefore different from the transaction identifiers used in the inter-MSG protocol to identify transactions that involve a number of inter-MSG messages.

The question here is:

Should such a reliable transmission mechanism be used for error control on the MSG-to-MSG paths?

Our position with regard to error control for MSG-to-MSG paths is :

1. The most effective error control mechanism for the MSG-to-MSG application is that described by Cerf and Kahn (i.e., that used in tne InterNet or TCP protocol).

MSG-to-MSG Protocol for the ARPANET i4-8

MSG Design Specifi^ation 1/23/76

U

\ t

2.

3.

4.

The overhead incurred by uoinp a TCP-like error control mechanism would not significantly degrade performance for the NSW MSG application.

Use of a TCP-like mechanism would approximately double the time and effort required to implement inter-host MSG.

The TCP mec MSG-to-MSG implementat enable TCP- messages . bytes are r support TCP believe tha error contr "higher lev protocol.

hanism can be made orthogonal to the protocol and to a properly designed MSG ion. That is, the information required to like error control would envelope inter-MSG We estimate that 5 or 6 additional 8 bit equired for each inter-MSG message to -like error control. Furthermore, we t the processing required to perform the ol function can occur- in series with the el" processing required to implement the MSG

It is not clea than that normally v/ill be re quired by inter-host MSG spec control fo r the MSG for inter- MSG messa required t o support implementa tlons sho be necessa ry to add experience indicate MSG-to-MSG paths is

r, at presen provided by the NSW app

ification do -to-MSO path ges include TCP-like er

uld be done TCP-like er that the la resulting i

t, whether erro ARPANET host to licat ion. Ther es not include s nor does the fields for the ror control. H with the expect ror cc»i':rol lat ck of error con n unacceptable

r control stronger host communication

efore, the initial TCP-like error transmission format information ov/ever, the MSG ation chat it may er, should trol for the oerformance.


■ -


5. MSG-to-MSG Transnission Formats for the ARPANET

This section specifies in detail the formats for the MSG-to-MSG protocol commands as sent over ARPANET connections. Only the syntax of the commands is specified here; for a discussion of the semantics of the MSG-to-MSG protocol see section 3 of this document.

MSG-to-MSG Formats for the ARPANET 5-1

i mm

tamm

MSG Design Specification 1/^3/76

5.1 General format for MSG-to-MSG nes-apes:

An MSG-to-MSG message is a sequence of 8 bit bytes. The first two bytes contain the length of tne message in bytes; the third byte is a command code that identifies an MSG-to-MSG protocol item; and the remaining bytes contain information relative to the command.

• length * command * data *

2 1 length - 3


^^^^^^^


5.2. Formats for Messape Components

1 . Process names:

As described i.i Section 2, a process name has four components which specify a host, a host incarnation number, a generic process class, and a process instance number. The representation for process names at the MSG-to-process interface is :

* host * host * process * count * string * * * incarnation # * inötance # * * *

2 2 2 1 count

Host is a 16 bit host address. (Whether the host address is an ARPANET host address or an NSW host address whose correspondence to an ARPANET host address is defined by a table MSG maintains is to be decided shortly.) If MSG is modified to allow processes with no generic names, the null generic name will be represented by a zero length string.

For a generically addressed message the destination process name is only partially specified. Either only the generic process class is specified, or only the host and generic class are specified in a generically addressed message. The other components are left un'pecifled. "Unspecified" is a special value used in generically addressed messages for host, host incarnation #, and process instance *. Unspecified is represented by two zero bytes.

When a process name appears as the parameter of an MSG-to-MSG message, the host component of the name need not be represented explicitly since it is implicit from the hosts of the sending and receiving MSGs. There are two representations for process names a^ Lhe MSG-to-MSG level: normal and compact. The only difference in the two is the representation of the generic process class. In the normal represenation the p-eneric class is represented by a string whereas in the compact form it is represented by a one byte generic class code. MSG implementations must be able to deal T.;icn both representations for process names. The compact representation is defined to allow for greater transmission efficiency. Use of the reneric codes is internal to MSG in the sense that the codes never appear in a process name given by MSG to an MSG process or accepted by MSG from an MSG process. Generic class codes for the NSW will be defined in the near future.


MSC Design Specification 1/23/76

Normal Format: count < 128 (5 + count bytes)

* hosl * process * count * string * * incarnation # * instance # * * *

1 :ount

Compact Format: Generic code >= 128 (5 bytes)

» host process * generic * * incarnation # * instance # * code *

2 2 1

Generic code = 128 + n (n < 128) where n = inteper which specifies a generic class Xi - 0 ~ null (i.e., process has no generic name)

2. Host Incarnation #:

16 bit (2 byte) number. 0 = unspecified (used for generically addressed messages) 1-255 reserved for special use

3. MSG transaction Identifiers (source-id. destination-id)

» MSG id *

16 bit (2 byte) number

MSG-to-MSG Formats for tne ARPANET 5-4

imm^imtmtm

li MSG Design Specification 1/23/76

4, Alarm code

* acode *

2

16 bit (2 byte) number.

5. Failure/Rejection cedes

* reason *

2

16 bit (2 byte) number. See descriptions of individual messages for discussion of

specific codes. Values have not yet been assigned, nor are those codes given necessarily exhaustive.

MSG-to-MSG Formats for the ARPANET

- HUM


5-3 Identifying Transactions-

In the format specifications that follow all Inter-MSG messages concerned with inter-process transactions carry the source and destination process names as well as the MSG source and destination transaction identifiers. The redundancy provided by the process names is useful to an MSG in detecting and recovering from protocol errors or violations resulting from malfunction of a remote MSG. With the exception of MESS messages, all protocol messages will fit into a single ARPANET packet (assuming the compact representation of process names or generic name.! of a few characters); hence, the cost associated with the redundancy is not great.


■ mm*

^^^^mm r— —


5.U MSG-to-MSG protocol messages

1. MESS(src-proc, dst-proc, handling, src-id, dst-id, message)

* length * Mfc^sS •* src-id * dst-id * First byte * Handling

2 12 2 1 1

• src-proc * dst-proc * message *

5+j 5+k M

length = 19+j+k+M ,j = # chars in source generic name / 0 if compact format, k = # chars in destination generic name / 0 if compact

format. MESS = 8 (10 octal) Handling = bit flags (numbered 0-7 from left to right)

bit 0 - generically addressed message bit 1 - sequenced message bit 2 - synchronization mark on message bit 3 - immediate decision on delivery (prohibit HOLD)

First byte - Position of first byte of the message (zero is the position of the first bvte of the length field of the MSG-to-MSG message)

2. MESS-0K(src-proc, dst-proc, src-id)

* length * MESS-OK * src-id * src-proc * dst-proc *

2 1 2 5+j 5+k

length = 15 + vi-»-k MESS-OK - 9 (11 octal)

MSG-to-MSG Formats fo- the ARPANET 5-7

11 wiiaMliTl \THnm iiTnimiBi^ ■


3. MESS-REJ(src-proc, dst-proc, src-id, reason)

* lenpth * MESS-REJ * src-id * reason * src-proc * dst-proc *

2 12? 5 + J 54-k

length = 17+J+k MESS-REJ = 10 (12 octal) reason = To be specified, but includinp;;

dst-proc unknown no buffer space message queue for process full

4. MESS-HOLD(src-proc, dst-proc, src-id, dst-id)

* length * MESS-HOLD * src-id * dit-id * src-proc * dst-proc *

2 12 2 ^ 5-fk

length = 17+j+k MESS-HOLD = 11 (13 octal)

5. H0LD-0K(src-proc, dst-proc, src-id, dst-id)

* length * HOLD-OK * src-id * dst-id * src-proc * dst-proc *

2 1 2 2 5+j 5+k

length = 17+J+k HOLD-OK =12(14 octal)

MSG-to-MSG Formats for the AKPANET

iimniaini I ITII in i in - -, r, ^.^.^ ., ^ _: |. ,, t,^^^^,^^. ^ f


6. MESS-CANCEL(src-proc, dst-proc, sro-^d, dst-id, reason)

* lengtli * MESS-CANCEL » src-id * dst-id » reason

2 1 2 2 2

* src-proc * dst-proc *

J+J 5+k

length = 19-M+k MESS-CAKCEL =13(15 octal) reason = To be specified, but including;

srj-proc unknown ^c-id unknown essape rescinded 5rc-proc terminated no buffer soace

7. XM1T(src-proc, dst-proc, src-id, dst-id)

» lenpth * XMIT * src-id * dst-id *

2 12 2

length = 17+J+k XMIT = U (16 octal)

AlARMCsrc-proc, dst-pr ;, src-id, acode)

s.^c-p oc * dst-proc *

'5+j 5+k

* length » AL,,

2 1

src-id * acode * src-proc * dst-proc *

2 2 5-M 5 + k

length -- 17 + j+k ALARM = 16 (20 octal)


MSG Desipn Sped float ion 1/23/76

9. ALAHM-0K(src-proc, dst-proc, src-idN

* length * ALARM-OK * src-id * src-proc * dst-proc *

2 1 2 5+.1 5+k

length = 15+j+k ALARM-OK = 17 (21 octal)

10. ALARM-REJ(src-proc, dst-proc, src-id, reason)

* length * ALARM-REJ * src-id * reason * src-proc * dst-proc *

2 12 2 5+J 5+k

length = 17+j+k ALARM-REJ = 18 (22 octal) reason = To be specified, but including:

dst-proc unknown dst-proc not acceptinR alarms alarm already queued for dst-proc

11. CONNECTION-OPENCsrc-proc, dst-proc, src-id, dst-id, conn-id, type, socket.)

* length * CONN-OPEN * src-id * dst-id * conn-id * type

2 12^22

* socket * src-proc * dst-proc *

4 5+1 5+k

length - 25 + .1+k CONN-OPEN = 20 (24 octal ) type: 0 - Teletype (TELNET)

bit 0 -»- b^'ze - binary send/receive pair + size bit 1 + size - binary send -♦■ size


—Ml —

MSG Design Specification 1/?

bit 2 -♦- size - binary receive + size socket: 32 bit socket number = N

Teletype N = odd = send socket N+1 = even = receive socket

Binary send/receive pair (same as Teletype)

12. CONNECTION-CLOSECsrc-proc, dst-proc, src-id, dst-ii, reason)

* length * CONN-CLOSE * src-J ' * dst-id * reason * src-proc

2 1 2 2 2 5+j

* dst-proc *

5+k

length = 19+j+k CONN-CLOSE = 21 (25 octal) reason = To be specified, but including:

normal close src-proc terminated timeout of open byte-size mismatch type misi.iatch

13. CONNECTION-REJECT(src-proc, dst-proc, src-id, dst-id, reason)

* length * CONN-REJ * src-id * dst-id * reason * src-proc

2 1 2 2 2 5 + j

» dst-pr-.. *

5+k

length = 19+j+k

MSG-to-Mrv3 Formats for the ARPANET 5-11

mtaUBmmm -m n-- , —- , -- „^1 F. ^r |r ^


CONN-REJ = 22 (26 octal) reason = To be specified, but includinp:

dst-pnoc unknown dst-id unknown byte-size invalid type invalid timeout

14. NOP

» length * NOP »

2 1

length :: 3 NOP = 0 (0 octal)

15. ECHÜ(data byte)

* length * ECHO * data byte *

2 1 1

length = 4 ECHO =1(1 octal)

16. ECHO~REPLY(data byte)

length * ECHO-REPLY * data byte *

1

length = k ECHO-REPLY = 2(2 octal )

1SG-to-MSG Formats for the ARPANET 5-12

MSG Design Speci n.catiot 1/23/76

17. EXPER.IMENTAL(command, length, data)

* length * EXF * comand * data *

2 1 " N

length = 4+N EXP = 24 (30 octal)

18. SEND-STATUS(src-proc, dst-proc, src-id)

» length * SEND-STATUS * src-id * src-proc * dst-proc *

2 1 2 5+J 5+k:

length = 15+j+k SEND-STATUS = 4 (^ octal)

19. STATUS-OK(src-rroc, dst-proc, src-id, status bytes)

* length » STATUS-OK * src-id * src-proc * dst-proc

2 1 2 5-v%i 54k

* status bytes

N

length = 15+j+k+N STATÜS-0K = 5 (5 octal) status bytes = (to be defined)

20. STATUS-REJ(src-proc, dst-proc, src-id, reason)

* length * STATUS-REJ * src-id * reason * src-proc * dst-proc *

2 1 2 2 5+j 5+k

length = 17+j+k



STATUS-REJ = 6 (6 octal) reason = To he specified, but Includinp;

dst-process unknown

21. CLOSEO

* length * CLOSE »

2 1

length - 3 CLOSE = 7 (7 octc )

22. SYNCH( sender's incarnation #, receiver's incarnation //, version #, data)

ler.gth * SYNCH * sender # * receiver # * version # * data *

2 12 2 2 N

length = 9+N SYNCH =3(3 octal) s*-nüer/receiver #'s = Host incarnation #'s = 2 bytes version // = version of MSG protocol to be used by the sending

MSG = 2 bytes data = additional synchronization Information (to be defined)

23. PTCL-ERP.(error code, bad message)

* length * PTCL-ERR * error code * bad message *

2 1 2 N

length = 5+N PTCL-ERR = 25 (31 octal) error code = To be specified, but including:

command not implemented command unknown command syntax er^or

bad message = The Dad MSG-MSG message.

MSG-to-MSG Formats for the ARPAu'KT 5-1^4

■—rtMaM<a^iM|MMMa .... 1 immtmWM t«TiTi ..,.■, -r-1


5.5 Summary of Commands

Code Command Length Dec Oct

0 0 NOP 3 1 1 ECHO 4 2 2 ECHO-REPLY 4 3 3 SYNCH 9+N ^4 4 SEND-STATUS 15 + j+k 5 5 STATUS-OK 15+j+k^N 6 6 STATUS-REJ 17+j+k 7 7 CLOSE 3 8 10 MESS 19+j+k 9 11 MESS-OK 15+j+k

10 12 MESS-REJ 17+j+k 11 13 MESS-HOLD 17+j+k 12 U HOLD-OK 17+j^k 13 15 MESS-CANCEL 19+J+k 14 16 XMIT 17+j+k 15 17 reserved 16 20 ALARM 17+j+k 17 21 ALARM-OK 15+j+k 18 22 ALARM-REJ 17+j+k 19 23 reserved 20 24 CONN-OPEN 25+Jvk 21 25 CONN-CLOSE 19+j+k 22 26 CONN-REJ 19+J+k 23 27 reserved 24 30 EXP 4+N 25 31 PTCL-ERR 5+N

j = Extra bytes needed if src-proc name is not in compact format k = Extra bytes needed if dst-proc name is ^nf in compact format N = Number of bytes in ciata or messape contained in command.


—__

AD-A021 072 MSG; THE INTERPROCESS COMMUNICATION … · Agency of the Department of Defense and...

Documents

Transcript of AD-A021 072 MSG; THE INTERPROCESS COMMUNICATION … · Agency of the Department of Defense and...