Sandboxing and threading

ruby-talk
1

Dear all,
I have been pondering the idea of a RubyRobots for some time - this would be
based on the idea (I think someone referred to it as ‘robocode’) where people
can write a few snippets of code to control a robot and then battle different
robots against each other. There would be functionality to allow tournaments
of more than one robot, and regular playoffs could take place. As well as
being a lot of fun, it is a great teaching tool.

Naturally, being RubyRobots, I intend for the robots to be written in Ruby. As
well, being a Ruby enthusiast and not too great at C/C++, 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.

Ideally, I’d like to specify exactly which methods robots can use, but this
could be a bit tedious and possibly flawed. Looking quickly at the pickaxe,
it seems that $SAFE == 4 might be what I want, but I only want $SAFE == 4
while the robot code is running. So, I considered putting the robots in
threads - this solves some other implementation problems as well. However, I
have very minimal experience with Java threading, and none with Ruby’s
threads (which I’m told are easier). I have no real understanding of what is
threadsafe and what isn’t, though.

So to converge more rapidly on the point of this email, I am going to outline
below how I think this would work, and would appreciate the more thread-savvy
of you pointing out anything that is wrong, un-thread-safe, or worth watching
out for.

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. Each robot thread will have two event queues
associated with it. Robots will pass commands (“I want to turn left 30
degrees”) to the controller thread by putting events in the outgoing event
queue, and the controller will pass information (“you have been hit and lost
15 health points”) by putting it in the appropriate robot’s incoming event
queue. The robots will also be able to get some information (such as their
co-ordinates, health or ammo) by querying the controller directly, but this
will be only modifiable by the controller, and indirectly by the robots by
issuing commands to the controller.

Now, would this work as I’m proposing it? Is there a better way? What gotchas
should I be careful of? I’m particularly worried that making $SAFE == 4 will
prevent me from doing some things that I need to make it work.

Tim Bates

···

–
tim@bates.id.au

2

Hi,

···

In message “Sandboxing and threading” on 02/12/16, Tim Bates tim@bates.id.au writes:

Now, would this work as I’m proposing it? Is there a better way? What gotchas
should I be careful of? I’m particularly worried that making $SAFE == 4 will
prevent me from doing some things that I need to make it work.

It should work, at least I designed to work. If you have any problem,
tell me so that I can fix.

						matz.
3

Hi,

[…]

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

···

From: “Tim Bates” tim@bates.id.au

4

If you are more interested in the robot side of the problem (rather than
the control and administrative part), you could use the RealTimeBattle
code to provide the framework for your robots. RealTimeBattle allows
you to write your robots in any language and will provide the framework
for running tournaments, etc. You communicate with the robot via
standard in and standard out. The control language is fairly simple and
there is some attempt to represent physics realistically.

I started writing a framework for writing Ruby robots. I never had time
to complete it, but I’m willing to post the code if anyone is
interested.

The home page for RealTimeBattle is …

···

On Mon, 2002-12-16 at 03:00, Tim Bates wrote:

Dear all,
I have been pondering the idea of a RubyRobots for some time - this would be
based on the idea (I think someone referred to it as ‘robocode’) where people
can write a few snippets of code to control a robot and then battle different
robots against each other. There would be functionality to allow tournaments
of more than one robot, and regular playoffs could take place. As well as
being a lot of fun, it is a great teaching tool.

–
– Jim Weirich jweirich@one.net http://w3.one.net/~jweirich

“Beware of bugs in the above code; I have only proved it correct,
not tried it.” – Donald Knuth (in a memo to Peter van Emde Boas)

5

Well no, I’m more interested in the whole thing, but darn it, someone’s beaten
me to it. :wink: Doing it the way they do allows the robots to be written in any
language, but has drawbacks as well (one of which is, you can write robots in
a language other than Ruby!). I think that I will continue to do it my way,
if only for the exercise, and also because it would be simpler to get a robot
started so it would be more appropriate as a Ruby teaching tool; this is one
of my major aims.

Who knows, we might get a regular tournament going within the Ruby community
or something. I’ll think about that when it’s written.

Tim Bates

···

On Tue, 17 Dec 2002 04:07 pm, Jim Weirich wrote:

If you are more interested in the robot side of the problem (rather than
the control and administrative part), you could use the RealTimeBattle
code to provide the framework for your robots.

–
tim@bates.id.au

6

Likewise. My son and I are working on the game together. We also
call it ‘RubyRobots’. Will probably use RUDL, Log4r, and ROMP or DRb.
Looks like ours will only run on Windows though. It’s been the most
fun I’ve had programming in years.

  • Jim -
···

On Mon, 2002-12-16 at 03:00, Tim Bates wrote:

Dear all,
I have been pondering the idea of a RubyRobots for some time

7

Tim Bates tim@bates.id.au writes:

Who knows, we might get a regular tournament going within the Ruby community
or something. I’ll think about that when it’s written.

I’m looking forward to be a spectactor of such tournament! Please
release something or pointer to appropriate resources so that I know
what robot programming is, and in time, I hope, I don’t have to be a
spectator any longer.

YS.