Squirting s-expressions (sexps) over a socket/pipe has long been a
popular way to do interprocess/network communication between/to Lisp
dialect processes. It's easy to implement (since much of the machinery
is already there), and it's human-readable for easy debugging and testing.
You can do it with the reader and Racket evaluation sandboxes, as
Shriram suggested, and/or you can define your own restricted Racket
language or environment.
Or, if your protocol comprises only messages much simpler than arbitrary
code, you can still use the Racket reader, but instead of doing an eval,
you process each sexp manually. For example, read a sexp, which is the
message; then, if it's a pair, do a "case" on the CAR of the pair for
the message opcode symbol; then have the matching "case" clause look at
the CDR for arguments (perhaps doing it with an "apply" at this point),
etc. This might feel a bit like writing your own especially dumb toy
Racket interpreter, but instead of disabling and resource-limiting
problematic stuff, you simply never implement the problematic stuff.
This will also have different performance characteristics, which could
be better or worse than a Racket eval.
Security note: Whenever you're coding something using the reader on
potentially arbitrary input from untrusted sources, check the
documentation to make sure that no reader options/features are creating
vulnerabilities.
Shriram Krishnamurthi wrote at 09/08/2010 09:30 AM:
This is your friend:
http://docs.racket-lang.org/reference/Sandboxed_Evaluation.html?q=sandbox
--
http://www.neilvandyke.org/
_________________________________________________
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/users
