The foundational work on multiparty sessions  introduced the notion of global type for specifying the overall behaviour of multiparty protocols. The criterion for a session implementation to be correct with respect to its specification was formalised via the notion of projection: each process implementing the behaviour of a session participant was required to type-check against the local type obtained by projecting the global type on that participant.
However, the work  imposed strong restrictions on the syntax of global types, requiring all initial communications in the branches of a choice to have the same sender and the same receiver, and every third participant333We call “third participant” any participant which is not involved in the first communication of a branch. to have the same behaviour in all branches. Although these were useful simplifying assumptions in order to achieve multiparty session correctness, they limited the expressiveness of global types, ruling out relevant protocols. For this reason, more permissive choice constructors were investigated in subsequent work [2, 3, 10, 17, 14, 4, 6, 15, 11, 18]. A widely adopted relaxation of the choice operator, originally proposed in , allows third participants to behave differently in different branches, provided they are notified of which branch has been chosen. Later proposals [10, 17, 14] accommodate processes with output choices among different receivers, for instance a client choosing among different servers. On the other hand input races, namely input choices among different senders, continued to be considered as problematic. As a consequence, common protocols such as a server shared by different clients could not be specified by means of global types.
Recent proposals introduce more flexibility in input choices for processes [4, 6, 15, 11, 18]. The work  defines the property of race-freedom for sessions as the absence, at any stage of computation, of a branching between communications from different senders towards the same receiver leading to distinct target states. A rather permissive type system is proposed, which is shown to be both sound and complete for a range of liveness properties when restricting attention to race-free sessions. The work  also addresses the input race problem, referred to as the “+-problem” there. While the proposed syntax for global and local types is completely free, two well-formedness conditions are imposed on types, which are meant to prevent dangerous races. Sessions are synchronous in [11, 15] and asynchronous in , which is the work that is closest to ours. In that paper, input races are allowed under sophisticated conditions on projections of global types. These conditions track causalities between messages, and their soundness proof uses novel graph-theoretic techniques from the theory of message-sequence charts.
Consider for example the following session, where two participants and send concurrently a message to a third participant , which is ready to receive both messages in any order:
Example 1.1 (Confluent input race)
No matter whether communication is synchronous or asynchronous, this session incurs a race444 Either initially, if communication is synchronous, or after performing both outputs, if communication is asynchronous.. However, this race may be viewed as innocuous since after any branch is chosen, the input of the other branch is still available, leading to the same target state. Indeed, the race consists here of a choice between two different sequentialisations of concurrent inputs555If we had a parallel construct for processes, this situation would be represented as .. This kind of input race will be called confluent. The above session is well typed in , but not in [11, 18], where the syntax of global types forbids different senders in a choice. In , this session is also ruled out by the race-freedom condition.
By contrast, the following asynchronous session, where there is an apparent input race in the process of participant , is actually race-free according to  because it cannot evolve to a state in which both inputs of are simultaneously enabled. This kind of uneffective input race, which results from an agreement between the senders such that in every computation only one of them sends a message to the receiver, will be called fake.
Example 1.2 (Fake input race in asynchronous session)
This session implements the following protocol
between Alice, Bob and Carol, represented by
participants , and respectively:
Alice and Bob send each other the message “I arrived” and then they read their messages;
Alice sends Bob either the message “I will tell Carol”, after which she sends Carol the message “We arrived”, or the message “Please tell Carol”;
Bob reads either the message “I will tell Carol”, or the message “Please tell Carol” after which he sends Carol the message “We arrived”;
Carol reads the message “We arrived” with sender either Alice or Bob.
The session of Example 1.2 cannot be typed in [15, 11, 18] because the syntax of global types does not allow two participants to exchange messages by first performing both outputs and then both inputs. If we omit the initial exchange of messages between Alice and Bob, the resulting session can be typed in [11, 18] but not in .
Our goal is to devise a type system for asynchronous sessions that is permissive enough to accept the sessions of Example 1.1 and Example 1.2, while rejecting dangerous races that could lead to deadlock or starvation. In particular, we will not be able to type the sessions discussed in the introductions of [15, 18], since they both have a possibility of starvation.
For typing asynchronous sessions we use global types that split communications into outputs and inputs, following the approach advocated in [5, 8]. For instance, the session of Example 1.2 has the following global type: where and . Here denotes a send from to of label , denotes a receive by from of label , is an output choice with sender and receiver , and is an input choice with receiver and senders and .
The rest of the paper is organised as follows. In Section 2 we introduce our calculus for asynchronous sessions. In Section 3 we define the syntax and semantics of global types. In Section 4 we present our type system, illustrate it with some examples, and establish the properties of Subject Reduction, Session Fidelity and Lock-freedom. We conclude in Section 5 with a discussion on future and related work.
2 Asynchronous Sessions
We assume the following base sets: participants, ranged over by and forming the set , and labels, ranged over by and forming the set .
Definition 2.1 (Processes)
Processes are defined by:
where and and for and .
A process may be terminated, or it is an internal choice of outputs or an external choice of inputs. The symbol , in Definition 2.1 and in later definitions, indicates that the productions should be interpreted coinductively (they define possibly infinite processes) and that we focus on regular terms, namely, terms with finitely many distinct subterms. In this way, we only obtain processes which are solutions of finite sets of equations, see . So, when writing processes, we shall use (mutually) recursive equations.
In the following, we will omit trailing ’s when writing processes.
In a full-fledged calculus, processes would exchange labels of the form , where is a value. For simplicity, we consider only pure labels here.
In our calculus, asynchronous communication is handled in the standard
way, by storing sent labels in a queue together with sender and
receiver names. Receivers may then fetch messages from the queue
We define messages to be
where is the sender and is the receiver,
and message queues (or simply queues) to be possibly empty
sequences of messages:
The order of messages in the queue is the order in which they will be
read. Since the only reading order that matters is that between
messages with the same sender and the same receiver, we consider
message queues modulo the structural equivalence given by:
Sessions are composed by a number of located processes of the form , each enclosed within a different participant , and by a message queue.
Definition 2.2 (Networks and Sessions)
Networks are defined by:
with for any
Sessions are defined by:
where is a network, and is a message queue.
We assume the standard structural congruence on networks666 By abuse of notation, we use the same symbol as for structural equivalence on queues., stating that parallel composition is associative and commutative and has neutral element for any fresh .
If we write as short for for some . This abbreviation is justified by the associativity and commutativity of parallel composition.
To define the operational semantics of sessions, we use an LTS whose transitions are decorated by outputs or inputs. Therefore, we define the set of input/output communications (communications for short), ranged over by , , to be , where represents the output of the label from participant to participant , and the input by participant of the label sent by participant .
The LTS semantics of networks, defined modulo , is specified by the two Rules and given in Figure 1. Rule allows a participant with an internal choice (a sender) to send to the participant the label by adding it to the queue. Symmetrically, Rule allows a participant with an external choice (a receiver) to read the label sent by participant , provided this label is among the ’s specified in the choice. Thanks to structural equivalence, the first message from to that appears in the queue, if any, can always be moved to the top of the queue.
A key role in this paper is played by (possibly empty) sequences of communications. As usual we define them as traces.
Definition 2.3 (Traces)
(Finite) traces are defined by:
We use to denote the length of the trace .
we write as short for
We now introduce the notion of player, which is characteristic of asynchronous communication, where only one of the involved participants is active, namely the sender for an output communication and the receiver for an input communication. The player of a communication is the participant who is active in . The set of players of a trace is then obtained by collecting the players of all its communications.
Definition 2.4 (Players of communications and traces)
We denote by the
player of a communication
We denote by the
set of players of a trace
3 Global Types
As in [5, 8], our global types can be obtained from the standard ones [12, 13] by splitting output and input communications. The novelty is that we allow multiple receivers in output choices and multiple senders in input choices.
Definition 3.1 (Global types)
are defined by the following grammar:
where , for all and for and .
As for processes, indicates that global types are coinductively defined and regular.
The global type specifies that player sends the label with to participant and then the interaction described by the global type takes place. The global type specifies that player receives the label with from participant and then the interaction described by the global type takes place.
define as the smallest set satisfying the following equations:
The regularity of global types ensures that the sets of players are finite. In Section 2 we used the same notation for the players of traces. In all cases, the context should make it easy to understand which function is in use.
To avoid starvation we require global types to satisfy a boundedness condition.
To formalise boundedness we use to denote a path in
global type trees, i.e., a possibly infinite sequence of
communications . Note that a finite path is a trace in the
sense of Definition 2.3.
We extend the notation to denote
also the concatenation of a finite sequence with a possibly
The function gives the set of
paths of a global type, which is the greatest set such that:
If is the length of , we denote by the -th communication in the path , where . It is handy to define the depth of a player in a global type , .
Definition 3.2 (Depth of a player)
Let be a global type.
and define , the depth of in , as follows:
Note that iff . Moreover, if for all , then . Hence, if is a player of a global type and there is some path in where does not occur as a player, then .
Definition 3.3 (Boundedness)
A global type is bounded if is finite for all participants and all types which occur in .
The following example shows the necessity of considering all types occurring in a global type for defining boundedness.
Then we have: , whereas .
Since global types are regular the boundedness condition is decidable.
Global types in parallel with queues, dubbed type
configurations, are given semantics by means of the LTS in
Figure 2. The first two rules allow top level
outputs and inputs to be performed in the standard way. The remaining
two rules allow communications to be performed inside output and input
choices. These inside rules are needed to enable interleaving between
independent communications despite the sequential structure of global
types. For example, we want to allow
when , because, intuitively, outputs performed by
different players should be independent. This justifies the condition
in Rules [Inside-Out] and [Inside-In]. In
Rule [Inside-Out] we require all branches to be able to perform
the transition. This avoids for example:
which, in case we choose the right branch, leads to the configuration .
The shapes of the queues appearing in the premise of Rule [Inside-Out] ensure that is not the matching input for any output in the choice. In Rule [Inside-In], we consider only the branches with corresponding messages on top of the queue (called live branches), using the index set of ready messages defined as follows, where ranges over messages.
Given a set of messages and a queue , the index set of the “ready messages” in this set is defined by: .
The mapping plays a crucial role also in the typing rule for input choices, as we will see in Section 4. The condition means that there is at least one live branch. The condition for all ensures that the occurrence of does not generate a message that would “awaken” some dead, i.e. not live, branch of the choice. In the resulting choice, the dead branches become an arbitrary live branch (condition for some and for all ). In fact, such branches could also be omitted as they can never be awaken.
It is easy to check that the LTS of type configurations preserves boundedness of global types. Therefore, from now on we will assume all our global types to be bounded.
4 Type System
Global types are an abstraction of sessions. Usually, global types are projected to participants, yielding local types which are assigned to processes. The simplicity of our calculus and the flexibility of our global types allow us to formulate a type system where global types are directly derived for sessions, using judgements of the form . The typing rules are given in Figure 3.
Rules [Out] and [In] just add simultaneously outputs and inputs to global types and to the corresponding processes inside networks. The condition for all ensures that all players in are also players in . For example, this condition prevents the derivation of with and and arbitrary.
Rule [Out] considers all branches of the global type, since the choice of the sent message is arbitrary. This rule requires that the session resulting from the output of a branch be typed with the corresponding branch of the global type.
Rule [In] requires that the global type and the process read the same messages on the queue. To this end, it uses the index set of ready messages defined in Definition 3.5, collecting the indices of the live branches of the global type and of the input process777 As for global types, a branch of the input process is live if it has a corresponding message on top of the queue, and dead otherwise., and asking them to be equal (condition . This set of indices must not be empty (condition ). Only the branches of the global type and of the input process thus selected are compared in the premises of Rule [In]. Note that in this way we allow more freedom than in the synchronous subtyping for session types . In Rule [In], in order to ensure the condition for all required by the transition Rule [Inside-In], we want to prevent the enqueuing of messages that would transform a dead branch of the process or of the global type into a live branch. To this end, we introduce a predicate which forbids a global type to generate such messages. Let range over sets of messages.
The type is inactive for the set of messages , if holds, where:
The predicate looks for outputs in which produce messages in . The regularity of global types guarantees the computability of this predicate. Notice that also ensures that the network cannot produce messages in . This is due to the typing Rule [Out] prescribing that messages put on the queue by the global type be the same as the ones of the network.
For example consider the following sequence of transitions
Since the input and the message in
do not match, this session cannot be typed and therefore also the
should not be typable.
Without checking the inactivity predicate we can type this session by the global type
The problem here is that Rule [In] does not check the dead branches of the global type. The role of the inactivity predicate is just to ensure that the transitions will not awake dead branches. This is done by checking the outputs in the live branches. In this example the output is in the branch starting with the input and the queue contains . So the typing Rule [In] cannot be applied since does not hold.
Notice that the session in Example 1.1 has the transition
and the resulting session differs from that of the previous example
only for the label of the last input. Correspondingly, the global
only differ for the labels of the underlined inputs. Therefore
cannot be derived for the session
, since as we just saw
In fact, this is expected since the session can do a transition
that the type configuration cannot mimic.
the other hand, this session can be typed
by the global type
In this derivation Rule [Out] is applied first, and thus Rule [In] is applied only when the queue contains the matching messages for both branches. Therefore Rule [In] checks the continuations of both branches, and the inactivity predicate holds trivially for each of them.
Notice that bringing forward
the output from to in the global
does not enable us to type:
In fact, we cannot complete the derivation:
Indeed, we cannot apply Rule [In] to derive the top right judgement , since the only input does not match the message in the queue.
We can also type the following recursive version of Example 1.1:
where , and . A suitable global type is
as shown by the following derivation:
Our type system enjoys the properties of Session Fidelity and Subject Reduction. Moreover, it ensures the semantic property of Lock-freedom. Since every participant can freely perform outputs, to prove this property we only have to show that all inputs can be enabled. For lack of space we only give the most interesting case in the proof of Subject Reduction.
Theorem 4.2 (Session Fidelity)
If and , then and .
Theorem 4.3 (Subject Reduction)
If and , then and .
Proof. The proof is by induction on where
. Notice that
, which together with
implies . Then . Moreover is finite since
Let and with . Since must be derived using Rule [In], we get:
for all for all
where and for all
and . The
condition ensures that the transition
does not modify the
process of participant and does not dequeue any message with
receiver from . Therefore we get
and for all
. Moreover the transition can be done also if the process
is replaced by an arbitrary process and
top messages with receiver are dequeued. Therefore
It is easy to verify that . Then by induction we get and for all . Let where for some and all . From