1 Conversations with Fixed and Potential Participants Alexander Romanovsky and Paul Ezhilchelvan Department of Computing Science, University of Newcastle upon Tyne Newcastle upon Tyne, NE1 7RU, UK 1. Introduction The conversation concept [3] was introduced in order to structure cooperative concurrent systems and to provide their fault tolerance. Several processes take part in a conversation, which they enter logically at the same time (i.e. concurrently), and establish recovery points. While in a conversation, participants send/receive messages to/from other partici- pants only (violation of this rule is called information smuggling [2]). Error recovery is achieved by using a set of diversely designed alternates. When participants leave conver- sation synchronously after ensuring the acceptance test, they discard the recovery points. If the test fails, all participants restore the recovery points and try the next alternate. The exe- cution of conversations is atomic, indivisible and invisible from outside. Conversations may be nested freely, in which case only the participants of the containing conversation can take part in the nested ones. Several problems related to the applicability of conversations are discussed in [1]. The authors considered some solutions for resolving these problems but rejected all of them as unworkable. The first problem is related to using servers in conversations. The cli- ent/server paradigm assumes that servers may not know the list of all processes they will be serving and that it should be possible for the servers to make a non-deterministic choice of which to serve. This is why the canonical conversation scheme requires all servers to take part in a conversation even if they are not used due to the choice made dynamically inside the conversation. For example, if a conversation participant P1 can choose (inside the conversation) to use either server S1 or server S2 depending on the intermediate conversation results, the traditional approach requires both servers to enter the conversa- tion and to be kept inside until the conversation is over. We agree with the authors of [1] that the nature of servers is different from that of (active) conversation participants; that is why the traditional conversation scheme cannot solve this problem. Our solution, which extends the original conversation scheme, emphasises this difference and relies on treating them in different ways. The second problem is related to using shared objects. Unrestricted access to these objects can cause information to be smuggled out of the conversation. Unlike the authors of [1], we believe that one cannot expect any solution to work that does not serialise the execution of several conversations which use the same shared data because this would allow information smuggling between conversations. It is clear that if units of cooperation whose execution is atomic with respect to each are introduced, other these units, rather than individual processes should share the objects. An approach which relies