2.2.7 Ports and Connections

Ports and connections provide a means for a model to communicate with other concurrently and independently running models. This is different from importation, where a model is imported into an importation state of another model, and the combined model runs sequentially as a whole.

Connections are the communication channels between those concurrent models. After they are established, messages can be sent and received via those channels. Except when two connected models communicate, they are independent, and they have no other means to affect the behavior of each other.

A message is a tuple $<MN,\gamma>$ where $MN$ is the message name. The names of different messages may be the same. Actually, there is no way to guarantee uniqueness, since every model runs independently and concurrently. There is no restriction on $MN$, except that it should not contain a dot ``.'' $\gamma=\{\gamma_1,\gamma_2,...,\gamma_k\}$ is a set of parameters. Each parameter is a variable.

To establish a connection, a server model with at least one port must be started first. The $L$ link set of the server may be empty, since it usually does not connect to other models at start-up time. A client must also have at least one port. When it starts running, the simulation/execution environment connects it to the server(s) according to the $L$ set defined in it. That is, for each link $l_i=<PN_1,<M,PN_2>>$ defined in $L$, connect port $PN_1$ of the client model with port $PN_2$ of the server model(s) $M$. All the connections are established at start-up time. If any of the connections cannot be established, the client model cannot be simulated or executed. Its simulator or executor should immediately terminate, without even placing the client model in its default state(s).

If any of the following situations occurs, the establishment of connection $l_i=<PN_1,<M,PN_2>>$ is considered a failure:

• The model with $l_i$ in its $L$ set has no port called $PN_1$.

• Model $M$ cannot be found in a certain scope that the simulator or the executor is interested in.

• Model $M$ has no port called $PN_2$.

• Both $PN_1$ and $PN_2$ are in-ports.

• Both $PN_1$ and $PN_2$ are out-ports.

• Model $M$ does not respond to the connection request within a certain timeout (an implementation-dependent parameter).

Once connections between two models are established, they are never disconnected.

A port of a client may connect to multiple ports of one or more servers. Reversely, a port of a server may be connected by multiple ports of one or more clients.

Messages can be sent in any part of a model where action code can be written, such as the output $\lambda$ of a transition, and $EN$ and $EX$ of a state. To send a message, a model simply broadcasts an event whose name starts with the port name and a following dot ``.'' On the one hand, since neither the port name nor the message name can have a dot in it, the only dot in this representation separates the two parts. On the other hand, no transition handles an event sent internally with a name that contains a dot, the simulator or executor knows that it is an out-going message instead of a normal event.

Before the message is sent via a connection, the port name and the dot are removed. When the simulator or executor of the receiver receives this message, it first adds the name of its input port to the message name (again separated with a dot), and then broadcasts the event internally. The parameters of the message are regarded as the parameters of the event.