Multicompatibility for Multiparty-Session Composition

Modular methodologies for the development and verification of concurrent/distributed systems are increasingly relevant nowadays. We investigate the simultaneous composition of multiple systems in a multiparty-session-type setting, working on suitable notions of interfacing policy and multicompatibility. The resulting method is conservative (it makes only the strictly needed changes), flexible (any system can be looked at as potentially open) and safe (relevant communication properties, e.g. lock-freedom, are preserved by composition). We obtain safety by proving preservation of typability. We also provide a sound and complete type inference algorithm.


INTRODUCTION
Verification of communication patterns is of central importance for concurrent/distributed implementations of multiple communicating participants, as well as the possibility of ensuring good behavioural properties (e.g., lock-freedom).The shortcoming of many approaches to such an issue, both structured, -e.g., Mul-tiParty Session Types (MPSTs) [21,22] -and unstructured -e.g.Communicating Finite State Machines (CFSMs) [9] -is to design and analyse communicating systems as stand-alone closed entities: the designer/analyser has full knowledge of every and each interaction between any two participants.This hinders modularity features, which are crucial for the specification and development of large-scale, complex, distributed communicating systems.
Realistically, systems should be open, i.e. liable to interact with an external environment (typically other systems).In [3] an approach to (binary) composition -dubbed Participants-as-Interfaces (PaI) composition -was devised enabling to look at any system, even closed ones, as virtually open.In a nutshell, given two systems, one first selects two participants -one per system -which exhibit "compatible behaviours"; then transforms them into coupled gateways connecting the two systems.Such gateways work simply as "forwarders": a message intended for the interface-participant in one system is instead received by the gateway and immediately forwarded to the coupled gateway in the other system which, in turn, sends it to appropriate participants.For example, if one interface is ready to receive a message and another interface is ready to send the same message, then the gateway replacing the first interface will forward the received message to the gateway replacing the second interface.Essentially the gateways are obtained from the interfaces by adding forwarding of messages between them.Graphically This composition mechanism is "conservative", i.e. it makes only the strictly needed changes; and "flexible", i.e., it allows to look at any system as potentially open.The PaI approach was exploited in a number of papers for both MPTSs [4,5] and CFSMs [3,6,8], where another essential feature of this approach was proved: safety.Safe composition mechanisms being those that do not "break" any relevant property of the single systems.A drawback of the above mentioned investigations on PaI is that they have been carried out for binary composition only; or for a restricted notion of multiple connection in a client-server setting [4].
In the present paper, we push forward the PaI composition, exploring the setting of multiple simultaneous composition of several sessions. 1Note that if we compose, two by two, several sessions using binary composition, we get to tree-like structures only.In fact, by looking at sessions as vertices and gateway connections as undirected edges, the only way to get a cycle using binary composition is by connecting two interfaces belonging to the same composed session.In order to illustrate the idea underlying PaI multicomposition and its related issues, let us assume to have four sessions, M 1 , M 2 , M 3 and M 4 , containing respectively four participants, h, k, v and w, that we decide to transform into gateways (if possible) enabling to connect the four sessions into a single one.For the sake of simplicity we abstract here from the way communications are performed and from the logical order of the exchanged messages.The drawing above represents the messages the participants do exchange inside their respective sessions.The composition of the four sessions then consists in replacing the participants h, k, v and w, chosen as interfaces, by gateways.Note that a message, say the  that in M 1 is sent to h, could be forwarded (unlike the binary case) to different other gateways.This means that an interfacing policy has to be set up in order to appropriately define the gateways.An interfacing policy for the present example could be for instance the one that forwards to w the  received by h; to k the  received by v; to v the 's received by w and k; to h the  received by w.According to such an interfacing policy, the interface participants are replaced by gateways as described below.We notice that such a composition cannot be done using the mechanisms currently available in the literature [3][4][5][6]8].
The key issue when implementing such a simple idea into a particular formalism is to ensure the above construction to be safe.In the binary case safety can be ensured by the duality of the interfaces [3,5,6,8].For client-server composition, the compliace of server interfaces with the client interface allows to obtain safe compositions [4].Here the sitation is more tricky; we shall preserve the system properties by identifying a correct notion of compatibility for PaI multicomposition (which we dub multicompatibility) in the setting of MPSTs.
In MPST approaches to session specification and verification, two phases are distinguished: implementation (where code is independently and distributively written for each single participant) and verification.The former can happen after the latter, as an analysis of existing code; or before, with a sound design of the communicating systems (and, e.g., the generation of APIs that will guide the programmers).MPSTs have spawned a variety of tools for the sound modular implementation of a communicating system [13,20,27,29,32,38,39]: the code is safe, as long as it is well typed.However, in the vast majority of the MPST literature [14,18,21,22,32,37], the verification of the whole session is treated as a single, centralised operation.More precisely the behaviours of sessions are described by global types prescribing the order and the type of the communications between session participants.The MPST literature dealing with modular verification and composition of open sessions is however still at its early stages [4,5,19,36].In particular the present paper is the first one dealing with the safe PaI composition of an arbitrary number of sessions.
Contributions and Structure of the Paper.This paper introduces a conservative, flexible and safe PaI multicomposition method based on the notions of interfacing policy and multicompatibility, thus improving on the state of the art [4, 5,19,36].In Section 2 we recall the MPST calculus of multiparty sessions with its type system, as defined in [4]: we note that well-typed sessions are lockfree.Section 3 contains our main contributions.In particular, a precise notion of interfacing policy (Definition 3.6) is identified for an arbitrary number of multiparty sessions; building on that, multicompatibility (Definition 3.8) is defined in terms of typability of any of the possible interfacing policies.PaI multicomposition for sessions is then given in terms of interfacing policies (Definition 3.12).It is safe since we prove that multicomposition of multicompatible sessions is typable (Theorem 3.17), and hence lock-free.In Section 4 we define an inference algorithm for the global types of an arbitrary session, if any.We prove the soundness and completeness of this algorithm (Theorem 4.7).Section 5 discusses related works and concludes the paper.

THE CALCULUS OF MULTIPARTY SESSIONS AND ITS TYPE SYSTEM
In the present section we recall the calculus of multiparty sessions and its type system as defined in [4], to which we refer for more detailed explanations and for proofs.We assume to have the following denumerable base sets: messages (ranged over by ,  ′ , . . .); session participants (ranged over by h, p, q, r, . ..); indexes (ranged over by , , , , . . .); sets of indexes (ranged over by , , . . .).
Processes, ranged over by , , , , , , . . ., implement the behaviour of participants.In the following and in later definitions the symbol ::=  will indicate that the productions have to be interpreted coinductively and that only regular terms are allowed.Then we can adopt in proofs the coinduction style advocated in [25] which, without any loss of formal rigour, promotes readability and conciseness.
Multiparty sessions are parallel compositions of pairs participant/process of the form p[].  where  ≠ ∅ and   ≠   for ,  ∈  and  ≠ .Multiparty sessions (sessions, for short) are expressions of the shape: where p  ≠ p  for 1 ≤ ,  ≤  and  ≠ .We use M to range over multiparty sessions.
In the above definition, the output process p!{  . }  ∈ nondeterministically chooses one message   for some  ∈  , and sends it to the participant p, thereafter continuing as   .Symmetrically, the input process p?{  . }  ∈ waits for one of the messages   from the participant p, then continues as   after receiving it.When there is only one output we write p!. and similarly for one input.We use 0 to denote the terminated process.
We assume the standard structural congruence ≡ on multiparty sessions, stating that parallel composition is associative and commutative and has neutral elements p[0] for any p.
To define the synchronous operational semantics of sessions we use an LTS, whose transitions are decorated by communications.

Definition 2.2 (LTS for Multiparty Sessions
).The labelled transition system (LTS) for multiparty sessions is the closure under ≡ of the reduction specified by the unique rule shown in Figure 1.
Rule [Comm-T] makes the communication possible: participant p sends message   to participant q.This rule is non-deterministic in the choice of messages.The condition  ⊆  ensures that the sender can freely choose the message, since the receiver must offer all sender messages and possibly more.This allows us to distinguish in the operational semantics between internal (output) and external (input) choices.Note that this condition will always be true in well-typed sessions.
Communications are triples of the form pq ranged over by Λ, Λ ′ , . ... We define traces as (possibly infinite) sequences of communications by:  :: where  is the empty sequence.We use | | to denote the length of the trace , where | | = ∞ when  is an infinite trace.We define the participants of communications and traces: We give now a very simple example, that shall be used throughout the paper in order to clarify the notions we introduce.
Example 2.3 (Working example).Let us consider a session with two participants 2 : Process  1 controls the entrance of customers in a mall (via some sensor).As soon as a customer enters,  1 sends a message start to the process  which controls a display for advertisements.After the start message,  displays a general advertising image.Process  does control also a sensor detecting emotional reactions as well as a card reader distinguishing regular from new customers.Such information, through the messages react, rc and nc is sent to  1 .Using that information  1 sends to  a customised image, depending on the kind of the customer, through message img.The processes of such a session can then be defined as follows where sets of alternatives are denoted by branchings.

⋄
Lock-freedom for multiparty sessions is defined as in [24,30].In words, each participant ready to communicate is never prevented from finding a partner exposing a dual communication action.Lockfreedom ensures progress for each participant, and hence deadlockfreedom.

Definition 2.4 (Lock-freedom). A multiparty session
Notice that we need to consider M ′ in the above definition, since otherwise the multiparty session p[q!.0] ∥ q[p?.p?.0] would be lock-free.
We recall now the type system of [4], in which sessions are directly typed by global types without using projections [21,22].If the global type respects a well-formedness condition (namely boundedness, see Definition 2.7), the typed session does evolve in agreement with what the global type prescribes (subject reduction and session fidelity) and lock-freedom is ensured.Definition 2.5 (Global Types).Global types are defined by: where  ≠ ∅ and   ≠   for ,  ∈  and  ≠ .
The type p → q : {  .G  }  ∈ formalises a protocol where participant p must send to q a message   for some  ∈  , (and q must    receive it) and then, depending on which   was chosen by p, the protocol continues as G  .The notation p → q : .G is used when there is only one message.The terminal symbol End denotes the terminated protocol.
The set of paths of a global type G, notation paths(G), is defined as the greatest set such that: Clearly, paths of global types are traces as defined after Definition 2.2.The set of participants of a global type is the set of participants of its paths: For any G, regularity of global types ensures prt(G) to be finite.
In order to ensure lock-freedom by typing, each participant is required to occur in all the paths from the root.
is finite for all participants p ∈ prt(G ′ ) and all types G ′ which occur in G.
Intuitively, this means that if p ∈ prt(G ′ ) for a subexpression of G which is a type, then the search for an interaction of the shape pq or qp along a path  ∈ paths(G ′ ) terminates (and recall that G ′ can be infinite, in which case G is such).As shown in [4, Example 2], it is necessary to consider all types occurring in a global type when defining boundedness.
Since global types are regular, the boundedness condition is decidable.Only bounded global types will be allowed in typing sessions.
The simplicity of the multiparty session calculus allows to formulate a type system deriving directly global types for multiparty sessions, i.e. judgments of the form G ⊢ M (where G is bounded).
Here and in the following, the double line indicates that the rules are interpreted coinductively [31,Chapter 21].
Definition 2.8 (Type System).The type system is defined by the axiom and rule in Figure 2, where sessions are considered modulo structural equivalence.
Rule [Comm] just adds simultaneous communications to global types and to corresponding processes inside sessions.Note that this rule allows more inputs than corresponding outputs, in agreement with the condition in Rule [Comm-T] (Definition 2.2).It also allows more branches in the input process than in the global type, just mimicking the subtyping for session types [17].Instead, the number of branches in the output process and the global type must be the same.This does not restrict typability as shown in [5], while it improves session fidelity as discussed after Theorem 2.13.The condition prt(G  ) \ {p, q} = prt(M) for all  ∈  ensures that the global type and the session have exactly the same set of participants.In this way we forbid for example to derive p → q : .End ⊢ p[q!.0] ∥ q[p?.0] ∥ r[] with  ≠ 0 arbitrary.The regularity of processes and global types ensures the decidability of type checking.Besides, it is worth also remarking that typability alone does not ensure boundedness of types as shown in the following example.

⋄
Example 2.10 (Typing the multiparty session of Example 2.3).It is easy to check that, for the multiparty session M 1 of Example 2.3, we can derive G 1 ⊢ M 1 with the derivation D of Figure 3, where To formalise the properties of subject reduction and session fidelity [21,22], the standard LTS for global types can be used.Definition 2.11 (LTS for Global Types).The labelled transition system (LTS) for global types is specified by the rules in Figure 4.
Rule [Icomm] makes sense since, in a global type r → s : {  .G  }  ∈ , behaviours involving participants p and q, ready to interact with each other uniformly in all branches, can do so if neither of them is involved in a previous interaction between r and s.In this case, the interaction between p and q is independent of the choice of r, and may be executed before it.For example (omitting final End) we have r → s : Subject reduction ensures that the transitions of well-typed sessions are mimicked by those of global types.
Session fidelity ensures that the communications in a session typed by a global type proceed as prescribed by the global type.

Theorem 2.13 (Session Fidelity
Note that, if Rule [Comm] had allowed more branches in the global type than in the output process as the subtyping of [17] does, then Theorem 2.13 would have failed.An example is Typability does ensure lock-freedom.
We notice that global types, as presented in this section, ensure properties of closed multiparty sessions, where all participant behaviours are fully described,

MULTICOMPOSITION AND MULTICOMPATIBILITY
As discussed in the Introduction, in the present paper we extend the PaI approach to the PaI multicomposition of closed sessions.
In order to exemplify the notions we introduce and their related formal definitions, we shall recur to the following example where we consider four sessions we wish to compose.Example 3.1 (Four multiparty sessions).Let M 1 be as in Example 2.3, and let us consider also the following multiparty sessions M 2 , M 3 and M 4 . Session Process  2 controls an image display.Images are provided by process  according to some parameters with sender  2 depending on the reaction acquired by a sensor driven by q and distinguishing the kind of customers on the basis of their cards.Process  is also able to receive a reset message even if  2 cannot ever send it. 2 and  can hence be implemented as follows.
2 = q?react.q!pars.q! rc.q?img. 2 nc.q?img. 2 Process  controls a sensor detecting the entrance of people from a door.Once someone enters, a message start is sent by  to process  3 which turns on a light.The reaction of who enters, detected by a sensor driven by  3 is sent back to , which, according to the reaction, communicates to  ′ the greeting to be broadcasted from the speakers.
The PaI multicomposition consists in replacing one participant per session identified as "interface" by a "gateway" (sort of forwarder).Any participant in a session, say h, can be considered as an interface.In particular, we can look at the behaviour (a process in our formalism) of h as what the session would expect from a number of outer sessions (through their respective interfaces).By looking at h as an interface then, whenever h receives (resp.sends) a message , this has to be interpreted as a message to be sent to (resp. to be received from) some other interface among the available ones.
Example 3.3 (Interfaces).For the sessions of Example 3.1 we shall consider the participants h 1 , h 2 , h 3 and h 4 as interfaces for, respectively, the sessions M 1 , M 1 , M 1 and M 4 .

⋄
By having several sessions, the gateways are not uniquely determined.In order to produce gateways out of interfaces we need to decide how the interfaces do interact.We hence call "interfacing policy" a description of a possible way interfaces could communicate with each other.To formalise such a notion we first associate to each process a set of processes doing dual communications with participants taken from a fixed set.We call "interfacing set" this set of processes.

⋄
Interfacing sets are finite, since they contain processes which only differ for the names of participants and these names belong to a finite set.
An interfacing policy is then obtained by choosing, for each interface, an element of its interfacing set having as participants the other interfaces.Of course one cannot expect an arbitrary interfacing policy to lead to a sound composition.Let us consider, for example, the sessions of Example 3.1 and an interfacing policy where we choose the following element of IS( 1 , {h 2 , h 3 , h 4 }): Note that, according to the above interfacing policy, the greeting depends on the reactions sent by the sensor driven by q.It is not difficult to check that there exists another valid interfacing policy for Π 4 =1 h  [  ], namely the one according to which the greeting depends on the reactions sent by the sensor driven by p. I.e. also Π 4 =1 h  [ ′  ] is an interfacing policy for the multiparty session where This policy is valid, since the multiparty session Π 4 =1 h  [ ′  ] can be typed by the following global type For a given multiparty session the number of interfacing policies is finite, since interfacing sets are finite.
Our PaI multicomposition requires that the sessions to be composed be multicompatible.We say that multiparty sessions are multicompatible if they are typable and their participants are disjoint and we identify an interface for each of them and a corresponding valid interfacing policy.

⋄
We have almost all the required notions to define the multicomposition of multicompatible multiparty sessions.The only missing piece is that of building the gateways, using the operation of process composition.Two processes can be composed only if they offer exactly matching outputs and inputs: in the composition the inputs always precede the outputs.
As done for the example in the Introduction, by abstracting from the way communications are performed, from branching and from the logical order of the exchanged messages, the above composition can be graphically described as in Figure 5.It is worth noticing that getting rid of the gateways, so that, e.g, r sends message start directly to p, would disrupt the conservativity of our composition method.Participants other than the interfaces would in fact be affected by the composition, since a number of input/output actions should be modified.

⋄
Remark 3.14.The definitions of interfacing set and interfacing policy have a set of participants as parameter.By using a set of messages as extra parameter, we could turn the gateways from "forwarders" to "message-rename-and-forward" processes, so adding extra flexibility to our composition method.The extension is easy and we did not make it explicit for the sake of readability.

⋄
The following lemma relates the global type of an interfacing policy with the global types of two among the multicompatible sessions.It says how the outermost communication in the global type of the interface policy can be related to the outermost communications in the global types of the involved interfaces.This result is crucial for the correctness of our PaI multicomposition.By hd(G) we denote the two participants to the outermost communication in G, i.e. if G = p → q : {  .G  }  ∈  , then we define hd(G) = {p, q}.

Lemma 3.15 (Relations between Types of Interfacing Policies and of Multicompatible Sessions).
Let the multiparty sessions {M  }  ∈ be multicompatible with respect to {h  }  ∈ and K.
and G   is locked for all   s.t. <  and We can now show that PaI multicomposition of multicompatible sessions is safe, since it can be typed.This is done by defining a function G with two arguments: a list of global types and a global type.This function, applied to the list of the global types of the sessions to be composed and to the global type of a valid interfacing policy witnessing their multicompatibility, returns a global type for the PaI multicomposition.By ⟨G  ⟩  ∈ we denote the list The addition of a global type at the end of a list of global types, notation ⟨G  1 , . . ., G   ⟩ • G, does not add the End type.Formally we define In words, a global type is locked if its first communication involves the interface but this communication cannot be done since: • either the interface is not involved in the first communication of the global type for the interfacing policy; • or the interface is involved in the first communication of the global type for the interfacing policy, but the communicating interface is not involved in the first communication of the global type for the corresponding session.
The function G (defined in Figure 6) returns the "merge" of the global types provided as first argument, inserting also the interactions corresponding to the forwarding of the messages sent to the interfaces, as described by the global type provided as second argument.The construction of such a "merge" proceeds coinductively according to the three clauses of the definition.
The first clause applies when the first unlocked global type in the list has an outermost communication involving an interface, and this interface occurs in the outermost communication of G together with an interface which occurs in the outermost communication of the corresponding global type in the list.The global type of the composition starts with the communication having as sender a participant which is not an interface (as prescribed by G   ), followed by the forwarding between the two involved interfaces as prescribed by G and then by the communication of the message from the interface which just received it to a participant which is not an interface (as prescribed by G   ′ ).The protocol continues by applying the function G to the global types obtained from G   , G   ′ and G by erasing the communications done.The continuations of G   and G   ′ are added at the end of the list (where G   and G   ′ have been erased) which becomes the first arguments in the applications of G, while the continuations of G become the second arguments in the applications of G.
The second clause applies when the first unlocked global type in the list has an outermost communication not involving interfaces.The global type of the composition starts with this communication and then continues applying the function G to the list obtained by erasing G   and by adding the continuations of G   at the end (as first argument) and to G (as second argument).
The third clause applies when the list is empty and G = End.Note that the function G is well defined, since the equations in clauses 1 and 2 are productive, i.e. they always unfold at least one constructor.

⋄
We have now the necessary machinery to show the safety of our session multicomposition.Theorem 3.17 (Typability of PaI Multicomposition).If the multiparty sessions {M  }  ∈ are multicompatible with respect to {h  }  ∈ and K, then the PaI multicomposition of {M  }  ∈ with respect to {h  }  ∈ and K is typable.

𝑖
The choice of the order in making the list We now show by coinduction that, in case G is total, we can derive

𝑖
We proceed by cases according to which among the three clauses defining G is applied.
Clause 1. Lemma 3.15 implies The definition of interfacing policy (Definition 3.6) implies that, for all  ∈  ′ , Then the PaI multicomposition is By coinduction the typings (1), ( 2), (3) and the statement (4) imply that, for all We have then the derivation given in Figure 8, where we only show the processes which are modified from the premises to the conclusion.
Clause 2. In this case from G   ⊢ M   we get By coinduction, the typing (5) implies for all where we only show the processes which are modified from the premises to the conclusion.Clause 3. Trivial.We conclude the proof by showing that the function G is total.Note that, when clause 1 is applied, the typings (1), ( 2), (3) and the statement (4) imply that the conditions required by Lemma 3.15 remain valid for the global types G ′  , G ′′  , Ĝ and the corresponding multiparty sessions for all  ∈  ′ .When clause 2 is applied the typing (5) implies that the conditions required by Lemma 3.15 remain valid for the global types G ′  and the corresponding multiparty

TYPE INFERENCE
The effectiveness of PaI multicomposition relies on the following facts: (1) the possible choices of participants to be replaced by gateways are finite; (2) there is a finite number of interfacing policies for a given session; (3) global types for sessions can be inferred, if any.
Facts (1) and ( 2) are clear from the previous sections.In this section we describe an algorithm to infer global types for sessions, by adapting to synchronous communication the algorithm of [16] in order to handle matching of input and output processes.
Since global types are regular terms, we represent them as finite systems of regular syntactic equations [1,15].We prove soundness and completeness of the algorithm with respect to the typing system: when applied to a session M, it finds all and only those global types that can be derived for M, if any.Note that, since a session may have more than one global type, to be complete, the algorithm needs to be non-deterministic.
The algorithm follows the structure of coSLD resolution of coinductive logic programming [2,[33][34][35], namely the extension of SLD resolution capable to deal with regular infinite terms and coinductive predicates.The key idea, borrowed from coinductive logic programming, is to keep track of already encountered variables to detect cycles and avoid non-termination.
A global-type pattern is a finite term generated by the following grammar. G where  is a variable taken from a countably infinite set.We denote by vars(G) the set of variables occurring in G.A substitution  is a finite partial map from variables to global types.We denote by G the application of  to G. Note that, if vars(G) ⊆ dom( ), then G is a global type.An equation has shape  ≖ G and a (regular) system of equations E is a finite set of equations such that  ≖ G 1 and  ≖ G 2 ∈ E imply G 1 = G 2 .We denote by vars(E) the set { |  ≖ G ∈ E}.A solution of a system E is a substitution  such that vars(E) ⊆ dom( ) and, for all  ≖ G ∈ E,  ( ) = G holds.We denote by sol (E) the set of all solutions of E. Note that E 1 ⊆ E 2 implies sol (E 2 ) ⊆ sol (E 1 ).
The algorithm takes in input a goal (a pair (, M)) and either fails or returns a set of equations E such that the solution for the variable  in E is a global type for the session M. Rules defining the inference algorithm are reported in Figure 9. Inference judgements are of the shape S ⊢ (, M) ⇒ E, where S is a set of goals; variables in S are pairwise distinct and different from  .
For a terminated session the algorithm returns one equation  ≖ End (Rule [A-End]).For other sessions (Rule [A-Comm]) the algorithm selects one of the matching pairs:  = q!{  . }  ∈ and  = p?{  . }  ∈  , with  ⊆  .The algorithm continues analysing all matching branches   and   .After having evaluated subsessions, the algorithm collects all the resulting equations plus another one for the current variable.The freshness condition on variables   ensures that the resulting set E is a regular system of equations.The side condition on participants ensures that the resulting global type associated with  satisfies the conditions on participants required by Rule [Comm] in Definition 2.8.The set prt(S; E; G) is defined as the set of participants of a global type, but with the following additional clause to handle variables: if  ∉ dom(E) and (, M) ∈ S ∅ otherwise Finally, Rule [A-Cycle] detects cycles: if the session in the current goal appears also in S, the algorithm can stop and return just one equation that unifies two variables.
Example 4.1 (Inference).Figure 10 shows the application of the rules of Figure 9 to the session of Example 2.3, where The sets of goals and equations above are listed according to the order in which they are produced in a possible execution of the algorithm implicitely described by the rules of Figure 9.
It is easy to verify that a solution is the global type given in Example 2.10.It is then useful to compare Figure 10 with Figure 3.

⋄
Some definitions are handy.We denote by  +  the union of two substitutions such that  ( ) =  ( ), for all  ∈ dom( ) ∩ dom().We denote by vars(E) the set {vars(G) ∪ { } |  ≖ G ∈ E}.We define  ⪯  if dom( ) ⊆ dom() and  ( ) =  ( ), for all  ∈ dom( ).Let E be a system of equations and S a set of goals.A solution  ∈ sol (E) agrees with S if (, M) ∈ S implies prt( ( )) = prt(M) for all  ∈ vars(E).We denote by sol S (E) the set of all solutions of E agreeing with S. We say that a system of equations E is guarded if  ≖  and  ≖ G in E imply that G is not a variable.Finally, E is S-closed if it is guarded and dom(E) ∩ vars(S) = ∅ and vars(E) \ dom(E) ⊆ vars(S).
Toward proving properties of the inference algorithm, we check a couple of auxiliary lemmas.
As usual S ⊢ (, M) ⇒ E means that this judgment belongs to a derivation in the system of Figure 9 having a judgment with an N, (M, G)   In this case we have and  ⪯  .□ Soundness and completeness state that the inference algorithm applied to a session finds all and only the global types which, if bounded, can be assigned to the session.Theorem 4.7 (Soundness and Completeness of Inference).
(2).From G ⊢ M we get ⊢ i M : G.By Lemma 4.6 this implies that there are E and  such that ⊢ (, M) ⇒ E and  ∈ sol (E) and  ( ) = G. □ Remark 4.8 (Termination).To avoid non-termination, the key idea, borrowed from coinductive logic programming, is to keep track of already encountered goals to detect cycles.
As it happens for (co)SLD-resolution in logic programming, the termination of our inference algorithm depends on the choice of a resolution strategy.Indeed, we have many sources of nondeterminism: we have to pick two participants of the session with matching processes and expand them using Rule [A-Comm], or try to close a cycle using the Rule [A-Cycle].A standard way to obtain a sound and complete resolution strategy is to build a tree where all such choices are performed in parallel and then visit the tree using a breadth-first strategy.The tree is potentially infinite in depth, but it is finitely branching, since at each point we have only finitely many different choices, hence this strategy necessarily finds all solutions.In case no rule can be applied, the algorithm fails.

CONCLUSION AND RELATED WORK
In the present paper we have addressed the problem of multiple protocol composition for MPSTs [14,18,21,22,32,37] using the calculus and the type system defined in [4].We extended the PaI approach devised in [3] and exploited in [5] for binary composition of MPSTs.By binary composition, however, only tree-like structures can be obtained, leaving out many compositional possibilities.
In [4] the PaI approach for MPSTs was adapted to multiple composition in a client-server setting, where many server-sessions can be "connected" to just one client-session.In the present paper, instead, all the sessions to be composed are peers and their gateways can freely interact.This was achieved by introducing the notion of multicompatibility, which boils down to identifying a typable "interfacing policy" (a session describing how gateways interact).
The gateways connecting the various sessions are hence defined in terms of such interfacing policy.We proved that lock-freedom (ensured by typability) is preserved by composition.It is worth remarking that, as shown by a simple working example, one could have many typable interfacing policies to choose among.A different approach to composition for MPST is taken in [36], where sessions with missing participants can be typed and composed when types are compatible.A limit of that work is that only finite processes are considered.
The formalism of MPSTs used for our investigation can be dubbed as bottom-up: no projection is used and sessions are checked against global types by means of a type assignment system.Multicomposition in a top-down MPST setting has instead been recentely addressed in [19].In a top-down MPST, communication protocols are explicity described as global types and, subsequently, by projecting them, local types are obtained for implementation.The present paper and [19] address then multicomposition from two orthogonal perspectives.In a sense, however, they both exploit the general idea of ensuring safe multicomposition by means of a safe interfacing policy.As a matter of fact, the "traditional" syntax of global types is extended in [19] in order to explicitely describe an interfacing policy inside the global types themselves.Its projectability enables hence to apply a composition operation at the global type level.Unlike our approach, the interfacing policy that "drives" the composition is rigid in the sense that it is univocally determined by the global types to be composed.The main advantage of our approach over [19] is hence the possibility of choosing among different interfacing policies for the same set of sessions.On the other hand, however, [19] possesses the relevant and expressive feature of enabling more than a single interface in a session.
In [23] the author devises a type assignement system in logical form for sessions, where just one type is present, processes are unnamed and communications are performed through an (implicit) single channel.Deadlock-freedom is ensured by typability only in case the session enjoys a race-freedom condition.In such a context the composition of two sessions with single interfaces corresponds to a particular form of Cut rule, where compatibility corresponds to duality.Thanks to the presence of a single communication channel and to the absence of process names, sessions can be composed by simply removing the interfaces.It is not possible of course to get any explicit global information about the behaviour of sessions because just one type is present.The setting of the present paper, by using global types, process names and multiple point-to-point channels is however definitely more expressive and realistic.Our notion of compatibility cannot reduce to duality and the use of interfacing policies enables to finely control the operation of composition.
In [11], forwarders are introduced in a Linear Logic interpretation of a MPST formalism.Such forwarders are in a proofs-asprocesses correspondence with coherence proofs, where coherence is the multiparty counterpart of (binary) duality.Forwarders can be safely composed through cut elimination, so allowing to "compose" two concurrent sessions.The precise relationship between the forwarders of [11] and our gateways is worth investigating.Besides, our multiple composition through interfacing policies could have a logical counterpart enabling to compose multiple forwarders.
By suitably combining the notions of multicompatibililty of the present paper and the one in [19], one could avoid to extend the syntax of global types as done in [19], retaining at the same time the possibility of having several possible interfacing policies to choose among, as in the present paper.Moreover, the result of the present paper could be extended to the case of more than one interface in the sessions to be composed.
In Remark 3.14 a simple (decidable) extension of the gateways, so that they can perform also some "message renaming", has been discussed.This idea could actually be pushed further, investigating the possibility of reordering messages, so implicitly introducing a form of asynchronous subtyping between gateways.This should be done with care, since in general asynchronous subtyping is undecidable, as shown in [10,28].
The idea underlying our multicomposition is likely to be applicable in future to other frameworks.The works in [26] and [18] explicitly give algorithms for the synthesis of global types from communicating finite-state machines, while [27] proposes a similar method to build graphical choreographies, expressed as global graphs.[32] develops instead a framework where global types are not necessary, relying on model and type checking techniques for verifying safety properties of collections of local types.Our notion of interfacing policy could be adapted to such frameworks.Then we could investigate whether the synthesis of global types/global graphs or the verification of properties via type checking does "lift" from the components to the composed session, proviso a type synthesis or checking is provided for the chosen interfacing policy.
MPSTs are characterised by the implicit or explicit presence of tools for checking/verifying session properties (type assignment, projectability, type checking, etc.).The application of safe compositional methods can however be investigated independently from such tools.This has been done for the formalism of CFSMs in [3,6,7] using the PaI approach for binary composition.Suitable adaptations of the notions of interfacing policy and multicompatibility could be hopefully devised in such setting.As future work we also plan to consider composition of MPSTs with asynchronous communications, taking advantage from the more liberal syntax of global types introduced in [12].

Figure 5 :
Figure 5: Representation of the composed session in Example 3.13.

Example 3 .
13 (A multicomposition of sessions).Let M 1 , M 2 , M 3 and M 4 be as in Example 3.1.In Example 3.9 it is shown that these multiparty sessions are multicompatible.A PaI multicomposition of the multiparty sessions then Rule[Comm]  must be applied to derive G ⊢ K and this implies October 22-23, 2023, Lisboa, Portugal Franco Barbanera, Mariangiola Dezani-Ciancaglini, Lorenzo Gheri, and Nobuko Yoshida

Figure 7 :
Figure 7: A type for multicomposition of Example 3.13.

Example 3 .
16 (A type for multicomposition).The global type of the PaI multicomposition of Example 3.13 can be obtained by applying G as defined in Figure6to ⟨G 1 , G 2 , G 3 , G 4 ⟩ and G, where G 1 is defined in Example 2.10, G 2 , G 3 , G 4 are defined in Example 3.1 and G is defined in Example 3.7.Figure7shows the resulting global type.

Figure 8 :
Figure 8: Derivation used in the proof of Theorem 3.17.
Technically, this is obtained by means of the notions of depth and of bounded type below.The -th communication in a path , where  ∈ N and 1 ≤  ≤ | |, is denoted by  [].
Some sensors managed by process  4 do acquire the first reactions of people getting into a hall with several Christmas lights.This reactions enable process  to send to  4 a set of parameters allowing to adjust the lights of the hall. 4 = s!react.s?pars. 4  = h 4 ?react.h 4 !pars.
⋄We shall prove that lock-freedom, ensured by typing on single sessions, is preserved by composition.The sessions of the above example are lock-free.Example 3.2.The multiparty session M 1 of Example 2.3 can be typed by the global type G 1 of Example 2.10, and the multiparty react.h 4 !rc.h 2 ?img. nc.h 2 ?img. This would lead to a composition where the gateway we substitute for h 1 would first expect from h 2 the message start to be forwarded to p.Such a composition would immediately get stuck, since no message start is ever handled by  2 and hence by the gateway we would substitute for it.Sound compositions will actually be the one induced by typable interfacing policies, which we dub as "valid".Definition 3.6 (Interfacing Policy).An interfacing policy K for a multiparty session Π  ∈ h  [  ] is a multiparty session Π  ∈ h  [  ] such that   ∈ IS(  , P \ {h  }) for all  ∈  , where P = {h  |  ∈  }.An interfacing policy is valid if K is typable.Example 3.7 (Interfacing policies).Let us consider the four sessions of Example 3.1.Then an interfacing policy for the multiparty session Π 4 =1 h  [  ] is the multiparty session Π 4 =1 h  [  ] where  1 = h 3 ?start.h 4 !react.h 2 !rc.h 2 ?img. 1 nc.h 2 ?img. 1  2 = h 3 !react.h 4 ?pars.h 1 ?rc.h 1 !img. 2 nc.h 1 !img. 2  3 = h 1 !start.h 2 ?react. 3  4 = h 1 ?react.h 2 !pars. 4 This policy is valid, since the multiparty session Π 4 =1 h  [  ] can be typed by the following global type Definition 3.8 (Multicompatibility).The multiparty sessions {M  }  ∈ are multicompatible with respect to {h  }  ∈ and K if they are typable and prt(M  ) ∩ prt(M  ) = ∅ for all ,  ∈  ,  ≠ , and h  [  ] ∈ M  for all  ∈  and K is a valid interfacing policy for Π  ∈ h  [  ].Example 3.9 (Multicompatible sessions).Example 3.7 shows that Π 4 =1 h  [  ] is an interfacing policy for Π 4 =1 h  [  ].Such a policy is valid, therefore the multiparty sessions {M  }  ∈ {1,2,3,4} are multicompatible with respect to {h  }  ∈ {1,2,3,4} and Π 4 =1 h  [  ].