From: Bill Kelly <billk@...>
Date: 2002-12-17T03:03:58+09:00
Subject: Re: Sandboxing and threading

Hi,

From: "Tim Bates" <tim@bates.id.au>
[...]
>   I want to write the 
> controller itself in Ruby. But of course, there needs to be some level of 
> separation between the controller and the robot, so that we don't have robots 
> cheating or doing dastardly things by manipulating the controller. So I need 
> to sandbox the robot somewhat. I'm just not sure what the best way to do this 
> would be.
[...]
> In a battle between n robots, I will have n + 1 threads - a controller thread 
> and a thread for each robot. The robot threads will have $SAFE == 4; the 
> controller, $SAFE == 0. 

An alternative might be to keep the controller process completely separate
from the client robots.  If the controller is a server allowing clients to
connect over TCP/IP, it could implement--for instance--a simple line-based
protocol (ala FTP, POP3, etc...)

You could provide a class for use by persons implementing robot clients
that handled all the commands allowed by the server, and handled
establishing the TCP connection to the server.  There'd be no reason for
anyone *not* to use your pre-provided class - they'd have the source
code.  And so long as the protocol implemented by the server just 
consisted of simple commands issuable by the client, the client should
be able to flail away banging whatever requests it wants at the server...
without there being a way to cheat.   [Unless you want to implement a
buffer-overrun exploit in your server, specifically as an easter egg
for cheaters.  ;-D ]


Just a thought...

Regards,

Bill