next up previous
Next: 7.4 An overview of Up: 7 Running remote code Previous: 7.2 A second approach

7.3 Towards a Web of interacting secure mobile agents

The MOO metaphor combined with the idea of `negotiation' between the agent's intentions and the `structure of the world', represented as a set of Linda blackboards storing state information on servers connected over the the Internet allows a simple and secure remote execution mechanism through specialized server-side interpreters.

Implementation of arbitrary remote execution is easy in a Linda + Prolog system due to Prolog's metaprogramming abilities. No complex serialization remote procedure/method call packages are needed. In BinProlog (starting with version 5.75) code fetched lazily over the network is cached in a local database and then dynamically recompiled on the fly if usage statistics indicate that it is not volatile and it is heavily used locally.

As an example, high performance file-transfer (actually known to be faster than well-known http as ftp protocols) is implemented by orchestrating Prolog based remote_run control operations which are used to trigger direct full speed transfers entirely left to optimized C built-ins like sock2file/2:

fget(RemoteFile,LocalFile):-
   remote_run(RF,fopen(RemoteFile,'rb',RF)),
   fopen(LocalFile,'wb',LF),
   term_chars(to_sock(RF),Cmd),
   new_client(Socket),
     sock_write(Socket,Cmd),
     socket(Socket)=>from_sock(LF,_),
     fclose(LF),
     sock_read(Socket,_),
   close_socket(Socket),
   remote_run(fclose(RF)).

from_sock(F,yes):-
   assumed(socket(S)),
   sock2file(S,F),!.

Once the basic Linda protocol is in place and Prolog terms are sent through sockets, a command filtering server loop simply listens and executes the set of `allowed' commands.

Despite Prolog's lack of object oriented features we have implemented code reuse with intuitionistic assumptions.

For instance, to iterate over the set of servers forming the receiving end of our `Web of MOOs', after retrieving the list form a `master servers' which constantly monitors them making sure that the list reflects login/logout information, we simply override host/1 and port/1 with intuitionistic implication:

ask_all_servers(ListOfServers,Question):-
  member(server_id(_,H,P),ListOfServers),
  host(H)=>port(P)=>ask_a_server(Question,_),
  fail.
ask_all_servers(_,_).

To specialize a generic server into either a master server or a secure `chat-only' server which merges messages from BinProlog users world-wide we simply override the filtering step in the generic server's main interpreter loop.

Implementing agents `roaming over' a set of servers is a simple and efficient high-level operation. First, we get the list of servers from the master server. Then we iterate through the appropriate remote-call negotiation with each site. Our agent's behavior is limited through security and resource limitations of participating interpreters, each having their own command filtering policies.

In particular, on a chat-only server our roaming agent can only display a message. If the local interpreter allows gathering user information than our agent can collect it. If the local interpreter allows question/answering our agent will actually interact with the human user through the local server window.

Such mobile agents are seen as `connection brokers' between participating independent server/client sites. For instance if two sites are willing to have a private conversation or code exchange they can do so by simply using the server/port/password information our agent can help them to exchange.

Note that full metaprogramming combined with source-level mobile-code have the potential of better security than byte-code level verification as it happens in Java, as meaningful analysis and verification of program properties is possible.



next up previous
Next: 7.4 An overview of Up: 7 Running remote code Previous: 7.2 A second approach



Paul Tarau
Thu Apr 3 10:26:39 AST 1997