AVirtual Terminal Protocol Based upon the "Communication Variable" Concept Gi~nter Schulze GMD-IFV, Darmstadt, FRG

and

Joachim BiSrger WRB-BERNI£T, Berlin, FR G

The ideas presented here have emerged from discussions within the PIX working groups "Higher level protocols" and "Virtu',d Terminal protocol" and present the agreement of the PIX virtual terminal protocol. PIX= A cooperation between several network activities in the technical/scientific area in the t:RG, sponsored by the Ministry of Research and Technology. The proposal is based on a general model of interprocess communication and describes how this model is used to fit tile requirements of terminal control. The result- ing class of terminal protocols uses one simple command set whereas the protocol for one specific terminal is derived by defining the appropriate data structure for that terminal. The complexity of a given terminal protocol therefore solely depends upon the complexity of its data structure. As an example, a protocol definition for a simple "line" and "page" mode terminal is given.

Keywords: Communication protocols, application orien- ted protocols, terminal compatibility, virtual terminal protocol, interprocess communica- tion, interprocess synchronisation.

Giinter Schulze, born in 1941, uni- versity degree of a Diplom-Ingenieur in 1968 (Technical University of Braunschweig, F.R. Germany). Until 1975 he was engaged in several industry development projects in the field of telecommunication, terminal and computer systems. In 1975 he joined the GMD (Gesellschaft fiir Mathematik und Datenverarbeitung), institute for teleprocessing. He is currently leading several development

projects for the connection of user equipment to packet switching networks.

Joachim Biirger, born in 1946, uni- versity degree of a Diplom-lngenieur in 1974 (Technical University of Berlin (West), F.R. Germany). Before joining the BERNET project staff in the end of 1975 he was engaged in an industry development project con- cerning radio data transmission and controlling public transportation by means of a central computer.

© North-Holland Publishing Company Computer Networks 2 (1978) 291-296

1. Introduction

Achieving compatibility within distributed termi- nal oriented applications has already been approached from various directions such as definition of a set of extended ISO 7bit characters [1], together with virtual terminal protocols, e.g. [ 2 -5 ] . Although this paper will also present a virtual terminal protocol

intended as a network wide standard it is believed

that this is not just another protocol of this type. The above mentioned protocols offer more or less

a set of primitives that leave some space for undetec-

ted misunderstandings with regard to the meaning and semantics of the protocol primitives. Often, the

meaning is left to the experience that the designer has

had with particular terminals or to the intuit ion of

the designer. Discussions between designers often result in deviation from the main objectives and it becomes necessary for them to define special rules, and new commands together with the associated error

messages. From the outset it was attempted within the PIX

groups to define a model for process to process com- munication [7], [6] and to derive from this model a

set of descriptive tools for the definition of applica- tion protocols. The proposed model is not formally

derived but is based on experience and experiment. In order to offer a manageable and extensible VTP

proposal, it is believed that a very simple and concise set of terminal commands can be constructed by the selection of a hierarchical data structure together with a common set of synchronization signals des- cribing the exchange of access rights to elements of the data structure. In such a model as described in more detail in the next section, many different terminal commands appear as basically identical but they operate on different levels of the data structure. Different terminal classes characterized by different complexity of their data structure have identical com-

mand primitives.

1 This paper has been presented at the Computer Network Protocols Symposium, held in Liege (Belgium) in February 1978 and organized by the University of Liege. The permis- sion to reprint this paper is gratefully acknowledged.

291

292 G. Schulze, J. BOrger / The "communication variable" concept

This paper is restricted to the description of the data exchange and data structure. It does not des- cribe date transportation functions, connection set- up and clearing primitives, resynchronization mecha- nisms etc..

2 . P r o c e s s t o p r o c e s s c o m m u n i c a t i o n

The model of process to process communication is based upon the assumption that the two communica- ting processes have defined a structurally identical set of "communication variables" (CV's) and that the communication consists of the exchange of access rights to these variables and of transport of update information between these variables (fig. 1). On top of such conventions finally the detailed structure of the CV's becomes visible and naming conventions for fields within CV's allow partial updates of CV con- tents.

2.1 Data structure

The data structure seen by the application may be, for example, a line or a page of IA5 characters, a form consisting of fields etc. In general the two processes have to initially define a common set of data structures and then assign at least one structure type to be used for actual data updates. "In general" in this context means that not necessarily all infor- mation for the structure definition and assignments have to be transmitted, some may be statically predefined by implementation.

With these assumptions in general three types of commands have to be used: - Definition commands (DEF): Description of a set

of data structure types (e.g. line structure and line length, from description etc.).

-Declaration commands (DCL): Selection of one data structure type and assignment to a CV-name,

Common data s tFk lC tk l re

communication

variable (s)

CV

i 1

II' ~A process

allocation of a CV (e.g. form assignment). - D a t a commands (DAT): Exchange of updates to

the "values" (contents) of CV's (e.g. updates to fields of a form). With these commands it is possible to form a hier-

archical structure where DEF's and DCL's at the particular level may only refer to types and allocated data fields belonging to the next higher level. For an example, having allocated a page at a particular level, it is possible to define a line structure and allocate the line at a lower level.

Due to this hierarchical structure, at a given moment in time a CV may be either undefined, defined and declared with respect to its type and location or actually allocated in storage.

2.2. Update and synchronization o f access to com- munication variables

We assume that the data structure types and the hierarchical structure of the CV's are known and realized in the local storage of both communicating processes. It is a pre-requisite to successfull communi- cation, that the actual knowledge about this data structure is identical in both processes.

Communication in this model is the updating of contents in the local realizations of the CV's and the transfer of access rights to CV's.

We therefore distinguish between - m e s s a g e s transporting all updates to the contents

of CV's which are produced by one data process- ing step of the sending process and are consumed by one data processing step of the receiving process,

- access control cycle, which describes the exchange of the right to update the contents of CV's.

- l i f e time o f contents o f a CV, the "value" of a CV exists from initialization until termination of the contents of the CV. Due to these conventions, the updates to a CV will

have the format as shown in fig. 2, where - E-bit: indicates whether 1 octet or 2 octet header

is used, - S-bit: synchronization bit, defines the access right

l

~ [ Ct,'- s v / / - - Neune ] I Data

2

Fig. 1. Process to process communication model. Fig. 2. Forma t of update to a communication variable.

G. Sehulze, J. BOrger / The "communication variable" concept 293

in the sense of "your turn" or "my turn", - V - b i t s : validation bits, define the life time of the

contents of the CV in the sense of the first, not first/not last, or last update.

- C V name: communication variable name, identi- fies the actually used CV. The communication will take place under control

of the synchronization-bit in the way shown in fig. 3, as an example.

If P1 initially has the access right (i.e. the right to change the contents of the corresponding CV) it will remain in the sending state until it gives the turn to the other side by setting the s-bit to 1. On receipt of S = 1 P2 leaves the receiving state and is now allowed to change the contents of the CV.

Because the S-bit is assigned to each CV individu- ally, the " turn" indicates that the other end has the right to change the contents only of that CV to which the S-bit is assigned. The CV specific nature of the S-bit allows the protection of selected fields of a screen, for instance by using the S-bit in combina- tion with two different CV's. This mechanisms avoids the need to define an explicit protect-primitive.

In the case of using a tree structure of CV's a correspondant is only allowed to change the contents of a CV if it has the turn of that CV as well as the turns of all lower level CV's. An example is illustrated in fig. 4.

The other control information (V-bits, V1 and V2) is used to initialize the contents of the communica- tion variable and should be interpreted in the fol- lowing way:

V1 = 0 : first update V2 = 0 : last update

The first update implies that the old contents of the CV have to be erased or the CV has to be ini- tialized before the received update is stored. The last

P 1

sending S = ]

r e c e i v i n g S = I

s e n d i n g

' ,l I "

P 2

I receiving

sending

receiving

Fig. 3. Example use of the synchronization-bit (s).

t i lxJ~lt ¢' t o ~ o l ] t c, Jl[ s o l

l I /:v,~ c~ : II ]

( : \ ;1/ = I I . !

I i

Fig. 4. Access rights in case of nested CV's.

update implies that the CV has to be updated with the received data, and the CV may only be erased after presentation of the contents to the user.

The redundancy contained within this mechanism (one bit would have sufficed) allows the implementor to use either the "first" and "not first" or "last" and "not last" indication depending for instance on the local capabilities of the physical terminal.

This implies that at the receiving side initializa- tion actions are only executed if V-bit(s) are set to zero according the following rule:

I INITIALIZE in case of V1 = 0 STORE update and PRESENT to user; INITIALIZE in case of V2 = 0

3. A virtual terminal protocol using communication variables

The terminal functions to be supported are des- cribed by means of one or several data structures and different updates to these data structure(s) with the corresponding synchronization signals.

The data structure types seen by terminal oriented applications may be, for example, a line of characters, a page of characters, a page of characters and attri- butes, a form consisting of fields, a sequence o f characters, etc.

Once the data structure is defined and a type is assigned to a CV, the updates to the contents must fit the data type characteristics and corresponding addressing conventions. Having defined a "page" structure for instance, this definition implies an absolute (random) addressing scheme tbr updating the contents of any position. An update to the con-

294 G. Schulze, J. B6rger / The "communication variable" concept

tents of a CV of the type "sequence" is by defini- tion only allowed in the sense of "next" element.

A collection of different types and the corre- sponding capabilities necessary for a wide range of terminal applications is not yet available, but the fol- lowing description will give some indications on the principles and a protocol as it has been derived for a first version, supporting a restricted set of terminal functions.

3.1. Mapping o f terminal functions

It is assumed that the terminal functions could be mapped onto a hierarchical tree of CV's. The root of this tree consists of one CV called CV O. From the functional point of view this CV presents the "con- trol unit" of the terminal and contains a description of its capabilities. The CV 0 could be used for the definition (DEF) of further substructures types and for declaration (DCL) of subordinate CV's. Such allocations are to be used for dimensioning the raw screen and selection of a character set etc. Parallel CV's are to be allocated if "split screen" or auxiliary device operations are to be supported for instance (fig. 5).

A further substructuring and allocation of CV's on a next lower level could be used for instance, for the support of formatting operations (fig. 6). The updates to these CV's then represent the data for unprotected fields.

The allocation of lower level CV's will operate as summarized below:

Definition of substructures on level n: n: CVi: . . .

DEF: type reference name, structure descrip- tion ( . . . character-set, attribute mask, size . . . . )

DCL:CViFname, type reference name, positioning description.

cv~

Control unJ t

f CV2

auxillary device

/...~

C%~1

main unit (screen)

... \ Fig. 5. Use with auxiUary devices.

cv~

Control unit

/ . . . \

unformatted mode

/ . . . \ CV3

formatted mode

/ , N Fig. 6. Use with formatted data.

Data exchange on level n + 1 corresponding to the substructure definition on level n: n + 1 : CVi/: DAT: (Addresses, Attributes, Text-

strings) In addition it is assumed that a mechanism for the

selection of the protocol type and version with a well defined initial master-shave relationship is contained in a common end-to-end protocol [8], and is there- fore not covered by the terminal specific command set.

Fig. 7 shows an example use of the virtual terminal protocol.

3.2. The intial version o f the virtual terminal

The terminal function listed below should be supported by the initial version: - operational modes:

a) "page" mode with direct addressing capabilit- ies of lines and columns a fixed size of 80 positions/line and 24 lines/page,

b) "line" mode with direct addressing capabili- ties o f columns only and 80 positions/line, At any time either mode a) or b) could be used; but within a session both modes could be alternately used,

- ha l fdup lex mode of operation, dialogue con- trolled by an ETX function,

- further functions: • accentuation function (attribute), • erasure, initialization of the whole screen, • direct cursor addressing, • support of only IA5 alphabet, coded accord-

ing to CCITT Nr. 5.

G. Sehulze, J. Bdrger / The "communication variable" concept 295

i n ] t i a l , < " N c o n t r o l ( A I

~ ] [Pa r ame te r fo r CVI ] ~l 1

~ I [Pa r ame te r t o r Ckl]

i C\I IS1 ;'~=x! ['IEX~']

/ I 1 I I~.q (,S=1 ; \~xH-- J I I FI!XT ] g d i a l o g u e on the

UllfOI~latt ed

~ o l i C\ 1 ('~= ] ;V=x] I - s . . . . . .

>~ i rH~u ] • ~ "~"- ' - - ' r~{ '2' l (S=93;\,= 1 )

I [ F i e l d d e fn . fo~ C\3] ,a

~ i ~ ~ 7 V 3 ' S : I ; \ X) o o

i\' IS= l ; \ :X}

. ~ [ lT}XIli<;=l; ', x} 3

7 I - r /x~ I cv=¢~,, ......... p,o g ~g I J tected f e ~>1 o o I--_.-- (~'3 I S ~ I ; \ = x I - - - ~

j I [ ~ ] / - - - t

i

I , ~ ¢ - ~ - - d - - - c~, I ,:n-x;', ~,,>

Fig. 7. Example use of the VTP.

Format d e f J n i t ions

Cont ro l o f on ly C\3 to o t h e r s i d e p r o - t o o t s t he t e x t o f CV1

d i a l o g u e only on " u n p r o t e c t e d " f ield.<

C Olllp I e t t., 1o rl~llt t erased alX' CV% released

3.2.1. Assignment of functions to communication variables

CV 0 will only be used to indicate which mode

should be used, i.e. line or page mode and the dimen- sions of the page and line are fixed.

The modes are referenced by fixed type reference

names:

Type reference structure name description 0 Line (1 ... 80) 1 page (1 ... 24,

1 ... 80)

The initial version will not support DEF com- mands. The selected mode will be assigned to CV1 by DCL commands within CVO. CV1 is restricted to DAT commands containing addresses, attributes and

textstrings.

3.2.2. The protocol For the implementation it is assumed that both

ends start as if they previously exchanged the follow- ing information:

CV 0: DEF: Structure 0: line (1 ... 80) Structure 1: page (1 ... 24, 1 ... 80)

DCL: CV-I: Structure 0

: -~'1 [ i [ t I I I , i ~ ] 1 1 ( I I [1 12:!( i l l h

, , f , . . . . . . ¢ . . . . I , I ± _2

i,

, J [ ...... L': ° 1 1 ~ ' _.{' ...... I

21 li~1, I ~' ' " '

(', hc'nd~ - - ~ , l n n m J , ~ l r ~ l , b , q u i r i : n , I , ' i a l l f i q H i

151 [~] , : : % ] ) g J ~ ~ ~'1 t ' l ] C ( i i u]](

b < _ i . : c t T h i N ( ~ I t ~ ~'@ i < ~ ] l l c d ]

¢ I in. ira& I pl4u m}dc

Fig. 8. Format to be used for the initial version.

The party having global initial control, can start with text exchange in the line mode and may switch

to page mode by assigning the structure reference 1 to CV 1 and back to line mode by assigning structure

reference 0 to CV1, etc.

Whether the roll up feature is used in line mode or not, is not visible by the protocol. It is assumed that this feature is only of local interest.

The initializing function - last or first update are realized by

- NL function in line mode - Erase whole screen function in page mode.

Fig. 8 shows the formats to be used, details could

be found in [9].

R e f e r e n c e s

[l] Standard ECMA-48, Additional controls for character image I/0 devices; ECMA, 1976.

[2] P. Schicker, H. Zimmermann, Proposal for a scroll mode virtual terminal, EIN/CCG/77/02, EIN-CCG, 1977.

[3] CEC, DG XIII, Data entry virtual terminal protocol, VTP-D/2, CEC, Luxemburg, 1977.

[4] E. Bauwens, F. Magne, The virtual terminal approach in the belgian university network, Universit6 de Liege, Belgium, 1977.

[5] Virtual device protocol, CII, Siemens, ICL, 1977. [6] Dr. E. Raubold, "Shared variable" based interproces

296 G. Schulze, J. BOrger / The "communication variable"concept

communication, PIX/HLP/GMD/77/02, 3. European Net- work User's Workshop, Laxenburg, 1977.

[7] F.R. Hertweck, E. Raubold, F. Vogt, X 25 Based process- process communication, Computer Network Protocols, Liege, Belgium, Febr. 1978.

[8] F.R. Hertweck, E. Raubold, F. Vogt, The ML-Protocol Description PIX/HLP/TEK/78/01.

[9] G. Schulze, J. Bbrger, The PIX Virtual Terminal Protocol PIX/VTP/TEK/78/01.

Note: PIX Documents may be obtained from GMD-IFV, Rheinstr. 75, D-6100 Darmstadt, F.R. Germany.

/

\

) /

/