Can someone give me pointers to where I can find more information
about interprocess communication (any form of) under Common Lisp? A
RPC-like feature would be good. Some technique for calling CLOS
objects remotely also.
danke.
From: Tim Daly, Jr.
Subject: Re: Interprocess communication in LISP
Date:
Message-ID: <wkadkk42vy.fsf@tenkan.org>
·········@netscape.net (Jules F. Grosse) writes:
> Can someone give me pointers to where I can find more information
> about interprocess communication (any form of) under Common Lisp? A
> RPC-like feature would be good. Some technique for calling CLOS
> objects remotely also.
>
> danke.
Do you mean between two lisps, or between a lisp and other processes?
CMUCL has something called wires which I've never tried. It's for
communication between two lisps, and there's some information about it
in the CMUCL documentation.
As for communication between a lisp and another program, most lisps
have extensions for pipes and sockets. I've always found it easier to
work out a simple custom protocol that does enough, than to even read
the CORBA spec.
-Tim
···@tenkan.org (Tim Daly, Jr.) wrote in message news:<··············@tenkan.org>...
> ·········@netscape.net (Jules F. Grosse) writes:
>
> > Can someone give me pointers to where I can find more information
> > about interprocess communication (any form of) under Common Lisp? A
> > RPC-like feature would be good. Some technique for calling CLOS
> > objects remotely also.
> >
> > danke.
>
> Do you mean between two lisps, or between a lisp and other processes?
Yes two Lisps, I forgot to mention. Thanks, I'll take a look at WIRE.
Another thing that came to my mind, is opening a stream between two
lisps (say, via socekts) and put a PRINT/READ/EVAL loop between the
two. Would that work?
Hi Jules F. Grosse,
> Yes two Lisps, I forgot to mention. Thanks, I'll take a look at WIRE.
> Another thing that came to my mind, is opening a stream between two
> lisps (say, via sockets) and put a PRINT/READ/EVAL loop between the two.
> Would that work?
Sure. Just realise that eval evaluates in the null lexical environment and
anyone able to connect to the evaluating server may be able to run
arbitrary code (so access to the port must be properly restricted,
preferably in depth (I wouldn't just rely upon firewalling it)).
You should be able to avoid using eval if the data is received in a known
format by the server. Here's an example of what I have been doing to
communicate between CLISP and CMUCL:
Client:
(format socket "~S~%~S~%~S~%" file-dir filename filename-prefix)
(force-output socket)
Server:
(let ((file-dir (read socket nil nil))
((filename (read socket nil nil))
((filename-prefix (read socket nil nil)))
...)
CL's ability to create a readable form of most objects makes this so easy.
You would only have to resort to other means to pass on the data if the
object is non-printable (i.e. the printed format begins with #< ).
Regards,
Adam
"Adam Warner" <······@consulting.net.nz> writes:
> Hi Jules F. Grosse,
>
> > Yes two Lisps, I forgot to mention. Thanks, I'll take a look at WIRE.
> > Another thing that came to my mind, is opening a stream between two
> > lisps (say, via sockets) and put a PRINT/READ/EVAL loop between the two.
> > Would that work?
>
> Sure. Just realise that eval evaluates in the null lexical environment and
> anyone able to connect to the evaluating server may be able to run
> arbitrary code (so access to the port must be properly restricted,
> preferably in depth (I wouldn't just rely upon firewalling it)).
And an ssl socket can be used to further secure the communications.
> CL's ability to create a readable form of most objects makes this so easy.
> You would only have to resort to other means to pass on the data if the
> object is non-printable (i.e. the printed format begins with #< ).
^not readable
I wrote earlier today:
> Sure. Just realise that eval evaluates in the null lexical environment and
> anyone able to connect to the evaluating server may be able to run
> arbitrary code (so access to the port must be properly restricted,
> preferably in depth (I wouldn't just rely upon firewalling it)).
>
> You should be able to avoid using eval if the data is received in a known
> format by the server. Here's an example of what I have been doing to
> communicate between CLISP and CMUCL:
>
> Client:
>
> (format socket "~S~%~S~%~S~%" file-dir filename filename-prefix)
> (force-output socket)
>
> Server:
>
> (let ((file-dir (read socket nil nil))
> ((filename (read socket nil nil))
> ((filename-prefix (read socket nil nil)))
> ...)
Here's something very scary and fascinating (thanks for the hint Marco):
it would still be possible to execute arbitrary code on the server using
the reader macro #. This is because *read-eval* is t by default. At least
*read-eval* should be set to nil:
� (let* ((*read-eval* nil)
�������� (file-dir (read socket nil nil))
�������� (filename (read socket nil nil))
�������� (filename-prefix (read socket nil nil)))
��� ...)
Note that the let* is critical. Marco's example also suggested wrapping
this all in with-standard-io-syntax (I don't think any other setting has
obvious security implications but they may assist communication between
implementations).
#. evaluates at read time. So you could easily denial of service the
server with something as simple as #.(sleep 3600) included in the input
stream. You can test this out using read-from-string. Compare
(read-from-string "#.(sleep 1)") and
(let ((*read-eval* nil)) (read-from-string "#.(sleep 1)"))
Of course you'd have to trap the error condition if you wanted the server
to be able to gracefully work around such input. And the use of read would
still allow denial of service by filling memory with arbitrarily long
input. But the surprise was that code evaluation was still possible in the
earlier case.
Regards,
Adam
> CMUCL has something called wires which I've never tried. It's for
> communication between two lisps, and there's some information about
> it in the CMUCL documentation.
I've used the wire facility and the `remote' package built on top of
it. It seemed to work well.
The remote package allows one CMU Lisp instance to make RPC-like calls
into another running CMU Lisp instance.
--
Fred Gilham ······@csl.sri.com
Jordan Hubbard: We have a crash bug. It needs to be fixed. We DO NOT
need to know how to print 3000 spaces in 11 different languages! :-)
Daniel Sobral: I concur. But if anyone wants to do it with loader,
: 3kbl 3000 0 do bl emit loop ; 3kbl will do the trick.
From: Tim Bradshaw
Subject: Re: Interprocess communication in LISP
Date:
Message-ID: <ey3of90thfi.fsf@cley.com>
* Jules F Grosse wrote:
> Can someone give me pointers to where I can find more information
> about interprocess communication (any form of) under Common Lisp? A
> RPC-like feature would be good. Some technique for calling CLOS
> objects remotely also.
There is a standard CL binding to CORBA, which is, of course,
overcomplex and large. But it does work, and it does integrate with
CLOS. It is supported, I think, by both Franz and Xanalys, and maybe
by other vendors. I'm not sure if any of the free systems have it.
--tim
From: James Amundson
Subject: Re: Interprocess communication in LISP
Date:
Message-ID: <aqgibc$9m9$1@info4.fnal.gov>
On Fri, 08 Nov 2002 05:44:01 -0600, Tim Bradshaw wrote:
> There is a standard CL binding to CORBA, which is, of course, overcomplex and
> large. But it does work, and it does integrate with CLOS. It is supported, I
> think, by both Franz and Xanalys, and maybe by other vendors. I'm not sure if
> any of the free systems have it.
There is an open source common lisp CORBA implementation: CLORB,
<http://clorb.sourceforge.net>. I have used it for a very simple project.
--Jim Amundson
·········@netscape.net (Jules F. Grosse) writes:
> Can someone give me pointers to where I can find more information
> about interprocess communication (any form of) under Common Lisp? A
> RPC-like feature would be good. Some technique for calling CLOS
> objects remotely also.
You should check on the Franz website (www.franz.com). They provide
an RPC package with Allegro CL.
--
Frederic Brunel
Software Engineer
In-Fusio - Mobile Game Connections
·········@netscape.net (Jules F. Grosse) writes:
> Can someone give me pointers to where I can find more information
> about interprocess communication (any form of) under Common Lisp? A
> RPC-like feature would be good. Some technique for calling CLOS
> objects remotely also.
http://www.franz.com/support/documentation/6.2/doc/rpc.htm
From the intro:
The purpose of the RPC utility is to allow separate Lisp images to
communicate with each other by remote procedure calls. This is
accomplished by:
* Defining a remote object representation that allows one Lisp
image to make references to data in another Lisp image.
* Defining a protocol to transfer a restricted set of Lisp data
types from one image to another.
* Adding functions that allow one Lisp image to call functions in
another Lisp image.
* Adding facilities to manage the retention, validation, and
garbage collections of remote references among a set of
communicating Lisp images.