ISO/IEC 4396-1:2023 システム間の通信と情報交換 | ページ 6

3.1

address

identifier that is a synonym for the fully qualified IPC-Process-Instance-name, which is a member of a distributed-IPC-facility (DIF) (3.32)

Note 1 to entry: An address is only unambiguous within the DIF (and is assigned by the DIF). This identifier can be assigned to facilitate its usefulness to the operation of the DIF, i.e. location-dependent.

3.2

application connection

shared state maintained by two communicating peer application entities (AEs) (3.3)

Note 1 to entry: Application connections go initially through an establishment phase, in which enough data is exchanged to establish a shared understanding between both AEs, to later proceed to the data transfer phase, in which both AEs exchange data. In Recursive Inter-Network Architecture (RINA), the establishment phase is handled by common application connection establishment procedure (CACEP) (3.17) , while the data transfer phase is the responsibility of common distributed application protocol (CDAP) (3.18) .

3.3

application-entity

ae

task within an application process that is directly involved with exchanging application information with other application processes (APs) (3.9)

3.4

application entity instance

AE-instance

AEI

instantiation of an application entity (AE) (3.3) within an application process (AP) (3.9)

3.5

application entity instance identifier

AE-instance-id

AEI-id

identifier which is unambiguous within the application entity (AE) (3.3)

Note 1 to entry: The AE-instance-id may be ambiguous within the application process (AP) name space (3.13) unless qualified by the application process name, application process instance id (3.11) , and the application entity (AE) name (3.6) .

3.6

application entity name

AE name

identifier from the application entity (AE) name space (3.8) which is unambiguous within the scope (3.55) of the application process (AP) (3.9)

Note 1 to entry: An AE name when concatenated with an AP name (3.12) is unambiguous within the AP name space (3.13) , as is an AE name concatenated with an AP name and an AP instance id (3.11) .

3.7

application programming interface primitive

API primitive

library or system call used by an application to invoke functions, in particular inter process communication (IPC) (3.39) functions, such as requesting the allocation of IPC resources

3.8

application entity name space

AE name space

set of strings which may be assigned to application entities (AEs) (3.3) of a given application process (AP) (3.9) and used to reference them by other applications in the same naming domain

3.9

application- process

AP

software program in a processing system (3.46) intended to accomplish some purpose

Note 1 to entry: An application process contains one or more tasks or application entities (AEs) (3.3) as well as functions for managing the resources (e.g. processor, storage, and IPC) allocated to this AP.

Note 2 to entry: Tasks are also application processes.

3.10

application process instance

AP instance

instantiation of an application process (AP) (3.9) on an operating system

3.11

application process instance id

AP instance id

identifier that is unambiguous within the application process (AP) (3.9) and is bound to an AP instance (3.10) in order to distinguish among multiple AP instances

Note 1 to entry: An AP instance id concatenated with an AP name (3.12) is unambiguous in the AP name space (3.13) .

3.12

application -process -name

AP -name

string assigned to a single application process (AP) (3.9) from an AP name space (3.13)

Note 1 to entry: An AP name is not assigned to any other AP while bound to the one to which it has been assigned.

3.13

application process name space

AP name space

set of strings which may be assigned to application processes (APs) (3.9) and used to reference them by other APs in the same naming domain

3.14

application protocol

protocol used between two application entities (AEs) (3.3) to perform operations external to the protocol machine (PM) (3.50) itself

Note 1 to entry: The distinguishing characteristic of application protocols is that they modify states external to the protocol.

3.15

assignment

operation that allocates a name in a name space (3.43) , essentially marking it as being in use

Note 1 to entry: Assignment makes names available to be bound. This allows certain portions of a name space to be “reserved” and not be available for binding (3.16) . The corresponding reverse operation, de-assignment (3.25) , removes it from use.

3.16

binding

function, F_M,N_S , that defines the mapping of a subset of elements of{ NS} to elements of{ M}

Note 1 to entry: This function is one-to-one and into. The operation, binding, binds a name to an object.

Note 2 to entry: Once bound, any reference to the name locates or accesses the object.

3.17

common application connection establishment procedure

CACEP

procedure to authenticate flow participants and initialize the application naming and protocol information

Note 1 to entry: CACEP naming and protocol information relates to the application protocol (3.14) that will be used by applications to exchange information (e.g. abstract and encoding rules, object model versions). In case of Recursive Inter-Network Architecture (RINA), the application protocol is common distributed application protocol (CDAP) (3.18) .

3.18

common distributed application protocol

CDAP

application protocol (3.14) component of a distributed application facility (DAF) (3.27) used to construct arbitrary distributed applications

Note 1 to entry: CDAP enables distributed applications to deal with communications at an object level, rather than forcing applications to explicitly deal with serialization and input/output operations. CDAP provides a straightforward and unifying approach to sharing data over a network without having to create specialized protocols.

Note 2 to entry: Distributed IPC facility (DIF) (3.32) is an example of a distributed application facility (DAF) (3.27) .

3.19

computing system

collection of all processing systems (3.46) (some specialized) in the same management domain

Note 1 to entry: There are no restrictions on the connectivity of computing systems.

3.20

connection

shared state between error and flow control protocol machine EFCP PMs (3.34)

3.21

connection-endpoint-identifier

CEP-id

identifier that is unambiguous within the scope (3.55) of an interprocess communication (IPC) process which identifies an error and flow control protocol machine EFCP PM (3.34) instance

3.22

connection-identifier

identifier internal to the distributed IPC facility (DIF) (3.32) that are unambiguous within the scope of communicating error and flow control protocol machine EFCP PMs (3.34) from that DIF

Note 1 to entry: The connection identifier is formed by the concatenation of the source and destination connection establishment procedure (CEP)-ids to identify the two directions of the connection.

3.23

data transfer control procedure

DTCP

half of an error and flow control protocol (EFCP) (3.33) that performs loosely bound (feedback) mechanisms, such as retransmission and flow control

Note 1 to entry: The DTCP protocol machine (PM) maintains state, which can be discarded after long periods of no traffic.

Note 2 to entry: One instance of a DTCP is created for each connection of a flow.

Note 3 to entry: All connections in Recursive Inter-Network Architecture (RINA) have flow control. Connections without flow control are denial of service attack vector.

3.24

data transfer procedure

DTP

half of an error and flow control protocol (EFCP) (3.33) that performs tightly bound mechanisms, such as ordering and fragmentation/reassembly

Note 1 to entry: One instance of a DTP protocol machine (PM) is created for each connection allocated.

3.25

de-assignment

operation that deallocates a name in a name space (3.43) , removing it from use

3.26

delimiting

operation to delineate the beginning and end of a service-data-unit (SDU) (3.56) and package it into the user-data field of a protocol-data-unit (PDU) (3.45)

Note 1 to entry: Delimiting is usually the first operation performed by the distributed IPC facility (DIF) (3.32) when an SDU is submitted.

Note 2 to entry: Delimiting enables the DIF to deliver the SDU as a unit of data to its recipient intact.

3.27

distributed application facility

DAF

distributed application

collection of application processes (APs) (3.9) in processing systems (3.46) that exchange information using interprocess communication (IPC) (3.39) and maintain shared state to cooperate in performing some task or function

Note 1 to entry: There are at least two APs and at least one processing system in each DAF.

Note 2 to entry: The DAF forms a black box to the members of the DAF who may be executing on one or more processing systems.

Note 3 to entry: In some DAF, all members of the DAF will be the same, i.e. a homogeneous DAF, while in others they may be different, i.e. a heterogeneous DAF.

3.28

distributed application name

whatevercast name (3.61) for the set of application processes (APs) (3.9) comprising a distributed application depending on the operation

Note 1 to entry: A whatevercast name is generally taken from the same name space (3.43) as the APs and is used to identify a distributed application. An important type of distributed application is a distributed IPC facility (DIF) (3.32) , i.e. the set of cooperating interprocess communication (IPC) (3.39) processes.

3.29

distributed application process

DAP

application process (AP) (3.9) that is a member of a distributed application facility (DAF) (3.27)

3.30

distributed application process name

DAP name

synonym for an application process (AP) (3.9) name

3.31

distributed application process synonym

DAP synonym

synonym for a distributed application process (DAP) (3.30) that is a member of a specific distributed application facility DAF (3.27) and is only unambiguous within the DAF (and is assigned by the DAF)

Note 1 to entry: The names may be structured to facilitate their use within the DAF.

3.32

distributed IPC facility

DIF

layer

collection of application process (AP) instances (3.10) that are cooperating to provide interprocess communication (IPC) (3.9)

Note 1 to entry: A DIF is a distributed application facility (DAF) (3.27) that does IPC.

Note 2 to entry: The DIF provides IPC services to AP instances of a DAF or IPC process instances of other DIFs via a set of application programming interface (API) primitives that are used to exchange information with the IPC process instances’ peer.

3.33

error and flow control protocol

EFCP

data transfer protocol used to maintain an instance of interprocess communication (IPC) (3.39) within a distributed IPF facility (DIF) (3.32) .

Note 1 to entry: The functions of this protocol can be used to provide reliability, order and flow control as required as determined by policy.

3.34

EFCP protocol machine

EFCP PM

instance of the error and flow control protocol (EFCP) (3.33) for a single connection

Note 1 to entry: An EFCP PM consists of two state machines loosely coupled through a single state vector: one that performs the data transfer procedure (DTP) (3.24) protocol machine (PM) (3.50) and the other that performs the data transfer control procedure (DTCP) (3.23) protocol machine (PM) (3.50) .

3.35

flow

binding (3.16) of a connection to source and destination ports

3.36

flow allocator

fa

task that handles requests to allocate a flow (3.35)

3.37

flow allocator instance

FA-instance

FAI

instance created for each allocation request to manage the flow for its lifetime

Note 1 to entry: The flow allocator instance will translate the (quality of service ) QoS requested by the Application-Process into specific policies and find the destination Application and determine if the allocation can be honoured. The FAI-identifier or port–id is returned to the application as a handle for referencing the allocation.

3.38

IPC process

IPCP

application process (AP) (3.9) whose primary purpose is managing inter process communication (IPC) (3.39)

3.39

inter process communication

IPC

service that allows two or more application process (AP) instances (3.10) to exchange data

3.40

IPC resource manager

IRM

component of a distributed application facility (DAF) (3.27) that manages its use of IPC

3.41

multiplexing task

mt

task within the interprocess communication (IPC) (3.39) process that performs multiplexing onto (N-1)-ports

Note 1 to entry: There is potentially one MT for each (N-1)-port.

3.42

name

unique string, N , in some alphabet, A , that, when seen within a name space ( NS)(3.43) unambiguously denotes an object or denotes a statement in some language, L , constructed using the alphabet, A

3.43

name space

NS

set of names,{ N}, from which all names for a given collection of objects are taken

Note 1 to entry: A name from a given name space may be bound to one and only one object at a time.

3.44

port

binding (3.16) of an (N)- error and flow control protocol (EFCP) protocol machine (PM) (3.34) instance to either an application entity (AE) instance (3.4) (if a distributed application facility (DAF) (3.27) ) or an (N)-IPC process instance [if a distributed IPC facility (DIF) (3.32) ] in the layer above

3.45

port id

identifier that is unambiguous within the scope (3.55) of the application process (AP) instance (3.10) and a distributed IPC facility (DIF) (3.32) interprocess communication process (IPCP) instance that is used to distinguish an instance of communication, i.e. a specific IPC allocation

Note 1 to entry: A port-id is a flow-allocator-instance-identifier (FAI-id) unique within the flow allocator (3.36) task, which identifies a flow-allocator-instance (FAI). FAI-id or port-id is returned to requesting applications as a handle to refer to this instance of IPC. The FAI maintains a mapping between the Port-id and the Connection-End-Point-id.

3.46

processing system

hardware and software that are capable of executing programs instantiated as application processes (APs) (3.9) that can coordinate using the equivalent of a “test and set” instruction, i.e. the tasks can all atomically reference the same memory

3.47

protocol

syntax and procedures of protocol data units (PDUs) (3.49) that specify the behaviour of two protocol machines (PMs) (3.50) cooperating for the purpose of maintaining shared state

3.48

protocol control information

PCI

that part of a protocol data unit (PDU) (3.49) that is interpreted by the protocol machine (PM) (3.50) in order to maintain the shared state of the protocol

3.49

protocol data unit

PDU

unit of data exchanged by protocol machines (PMs) (3.50) consisting of protocol control information (PCI) (3.48) and user data

3.50

protocol machine

PM

finite state machine that implements a protocol for maintaining a shared state

Note 1 to entry: A PM accepts input from its user and exchanges protocol data units (PDUs) (3.49) with a peer by transferring service data units (SDUs) (3.56) to a supporting service.

Note 2 to entry: The intent is to maintain the shared state with a corresponding PM, usually in another processing system (3.46) .

3.51

relaying task

RT

task within an interprocess communication (IPC) (3.39) process that performs relaying of protocol data units (PDUs) (3.49)

Note 1 to entry: There is one RT in each IPC process.

3.52

resource allocator

component of the interprocess communication (IPC) (3.39) process that manages resource allocation and monitors the resources in the distributed IPC facility (DIF) (3.32) by sharing information with other DIF IPC processes and the performance of supporting DIFs

3.53

resource information base

RIB

logical representation of the local repository of the objects for the distributed application facility DAF (3.27)

Note 1 to entry: Each member of the DAF maintains a RIB.

Note 2 to entry: A distributed application may define a RIB to be its local representation of its view of the distributed application.

Note 3 to entry: From the point of view of an OS model, this is storage.

3.54

RIB daemon

common component of an application entity (AE) (3.3)

Note 1 to entry: a common component of the AE is a task in a local application process (AP) (3.9) may request the resource information base (RIB) (3.53) daemon to provide information from other members of the distributed application facility (DAF) (3.27) either on demand, on an event, or periodically.

Note 2 to entry: The RIB daemon can optimize AP requests for information.

Note 3 to entry: From the point of view of an OS model, this can be considered storage management.

3.55

scope

function, MNS , which defines the class of objects,{ M}, that can be named with elements of{ NS}

Note 1 to entry: This is sometimes referred to as the scope of the name space.

Note 2 to entry: This can also refer to actual objects or the potential for objects to be created.

3.56

service data unit

SDU

contiguous amount of data passed by an application process or IPC-Process in an IPC API primitive with integrity preserved during delivery to a corresponding application process protocol machine (AP PM)

3.57

service data unit protection

SDU protection

interprocess communication (IPC) (3.39) function that protects service data units (SDUs) (3.56) from being given to the (N-1)- distributed IPC facility (DIF) (3.32) for delivery

Note 1 to entry: SDU protection may include (but is not limited to) integrity preservation, encryption, time-to-live functions and confidentiality.

3.58

synonym

multiple names assigned to the same object

3.59

unbinding

breaking the binding (3.16) between a name and an object

Note 1 to entry: Once unbound, any reference will not access any object.

3.60

user data

portion of a protocol data unit (PDU) (3.49) that is not interpretable by the protocol machine (PM) (3.50) and is delivered transparently to its destination application process (AP) (3.9) as a service data unit (SDU) (3.56)

3.61

whatevercast name

identifier that is the name of a set, usually taken from a name space (3.43) from the same name space as the members of the set with an associated rule

Note 1 to entry: When the name is referenced, the rule is used to select names from the set.

Note 2 to entry: Traditional multicast and anycast names are specific forms of whatevercast.

Note 3 to entry: A unicast name or address (3.1) can be considered as a degenerate case of a whatevercast name where there is only one element in the set.

Note 4 to entry: No assumptions are made about the static or dynamic membership of the set.