A Design Pattern for Distributed Rendezvous

In this paper we describe a design pattern for distributed rendezvous. We propose a variant of rendezvous that supports multiple server threads, each one devoted to a different client. On the server side a ForwarderObject is in charge of forwarding calls t

A Design Pattern for Distributed Rendezvous Ricardo Jimenez-Peris Marta Pati~o-Mart nez n Sergio Arevalo Universidad Politecnica de Madrid Facultad de Informatica 28660 Boadilla del Monte (Madrid), Spain frjimenez, mpatino, sarevalog@ .upm.es Keywords: Design Patterns, Rendezvous, Multithreaded servers, Distributed Systems, Object-Oriented Technologies. ABSTRACT In this paper we describe a design pattern for distributed rendezvous. We propose a variant of rendezvous that supports multiple server threads, each one devoted to a di erent client. On the server side a ForwarderObject is in charge of forwarding calls to the corresponding servers threads. This design pattern encapsulates both the forwarding algorithm and the server interface, so both can be changed independently. Guidelines are given on how to implement the design pattern in Ada 95, taking advantage of language speci c features such as streams. The Multithreaded Rendezvous pattern has been successfully applied in the implementation of Transactional Drago, an Ada extension to program fault-tolerant distributed applications. In applications based on rendezvous, when a client requests a service to a server, it issues a call to an entry point of the server with some parameters and then blocks till the server sends a reply with the service results. On the other hand, the server has its own ow of execution and at some points it accepts requests. When the server wants to accept a request for a particular service, it will block till a request for that service is received from a client. After that, the server executes the service, sends the results back to the client and then continues execution. Thus, rendezvous allows imposing a protocol of calls to clients. Distributed rendezvous implies that requests and replies may cross the network from the client node to the serve node. The implementation of distributed rendezvous ( g. 1) is very similar to the implementation of the wellknown RPC model 3]. In this implementation, when a server is designed, its services (or entry points) are speci ed by their name, and information about their parameters (types and modes) is also provided. From that speci cation, client and server stubs are automatically generated. The server stub is linked with the server and the client stub is linked with any client willing to use that server. The client stub must o er exactly the same interface the server o ers. The entry point implementation in the client stub must be able to locate the server, send it a message with the parameters of the call ( attened). Then, it waits for the server reply. When it is received it un attens the results and returns them to the client. Thus, the client makes calls to the remote server as it they were local. The server stub will have its own ow of control that receives messages from clients and then nds out which entry point is the message aimed to. It creates a task that knows how to un atten the message and how to call the entry point. T

his kind of tasks represents the client on the server side. When the server nishes the service, it returns the result to that task and the task sends a message back to the client stub with the attened results. When clients and servers interact by means of rendezvous, servers accept calls from di erent clients in their code. However, there are situations where it is not interesting that the same server accepts interleaving calls from di erent clients. For instance, in a transac-

Multithreaded Rendezvous:

1 INTRODUCTION Rendezvous has been widely used to synchronize concurrent programs. In a concurrent program the server o ers a set of services that clients call. In order to provide those services the client and server must synchronize, that is, the client should ask for a service and the server must be ready to execute it. Although rendezvous is provided as a basic mechanism in some languages, like Ada, distributed rendezvous is not. Using it in a distributed environment will be natural, especially for those that are used to work with it to build concurrent programs, but also to transform concurrent applications based on rendezvous into distributed ones. This work has been partially funded by the Spanish Research Council(CICYT), contract number TIC98-1032-C03-01 and the Madrid Regional Council (CAM), contract number CAM-07T/0012/1998.

第1页下一页