Information Technology Reference
In-Depth Information
Application Code
x = Registry.save("some data")
def save(data):
return RPCClient.request("Registry", "save", data)
Local Proxy
#follows generic Scribble protocol
def request(svc addr, op, args*):
c = create and join("RPCProtocol")
invite and send(svc addr, c, op, args*)
return c.receive()
RPC Library
core conversation primitives:
create
,
join
,
create and join
: creation
invite
,
invite and send
: initial request
send
,
receive
: in-conversation messages
Conversation Layer
event-based scheduling
ION channels
Fig. 8.
Translation of an RPC command into lower-level conversation calls
the OOI developers. To facilitate the use of session types without obstructing the exist-
ing application code, we preserved the interface of the RPC libraries but replaced the
underlying machinery with the distributed runtime for session types (as shown in Fig-
ure 8, the RPC library is now realised on top of the Conversation Layer). As wrappers
to the conversation primitives, all RPC calls are now automatically verified by the inline
MPST monitors. This approach was feasible because no changes were required to ex-
isting application code, but at the same time, developers now have the option to use the
Conversation API directly for conversations more complex than RPC. The next step in
this ongoing integration work involves porting higher-level and more complex OOI ap-
plication protocols, such as distributed agent negotiation [29], to Scribble specifications
and Conversation API implementations.
4.2
Benchmarks
The potential performance overhead that the Conversation Layer and monitoring could
introduce to the system is an important consideration. The following performance mea-
surements for the current prototype show that our framework can be realised at reason-
able cost. Table 1 presents the execution time comparing RPC calls using the original
OOI RPC library implementation and the conversation-based RPC with and without
monitor verification. On average, 13% overhead is recorded for conversations of 10
consecutive RPCs, mostly due to the FSM generation from the textual local Scribble
protocol (our implementation currently uses Python ANTLR); the cost of message vali-
dation itself is negligible in comparison. We plan to experiment with optimisations such
as pre-generating or caching FSMs to reduce the monitor initialisation time.
The second benchmark gives an idea of how well our framework scales beyond ba-
sic RPC patterns. Table 2 shows that the overall verification architecture (Conversation
Layer and inline monitor) scales reasonably with increasing session length (number of
message exchanges) and increasing parallel states (nested FSM size): “Rec States” is
