Approaches of interprocess communication

**Gabriel Genellina** · Feb 16 '07, 10:45 AM

Re: Approaches of interprocess communication

En Fri, 16 Feb 2007 07:11:36 -0300, exhuma.twn <exhuma@gmail.c omescribió:

Hi all,
>
Supposing you have two separate processes running on the same box,
what approach would you suggest to communicate between those two
processes.
>
Let me list the ones I know of:
>
* Sockets
Advantage: Supported per se in nearly every programming language
without even the need to install additional packages
Disadvantage: Lot's of code to write, and it's kind of silly to
communicate via TCP/IP if the processes run on the same machine.

Not so much code, really.
(And I would expect that making a connection to "localhost" actually does
*not* go down up to the network card hardware layer, but I don't know for
real if this is the case or not).

* Webservices
Advantage: Relatively easy to use, can work across different
languages
Disadvantage: Even more overhead on the TCP/IP side that simple
sockets, as really bulky SOAP messages need to be passed around.

You could use XMLRPC, wich is a lot simpler (but less powerful).

* CORBA -- similar to webservices but more complicated to code.

I would stay away as far as I could.

* Shared memory
I don't know much about this subject.

You forget the most basic one, stdio redirection. Easy, available on
almost any language, but limited to just a pair of processes.
You can add queues and messages.

Supposing both processes are written in Python, is there any other way
to achieve this? To me, shared memory sound the most suited approach.
But as said, I am still fuzzy in this area. Where can I find more
information on this subject?

Pyro appears to be a good alternative (altough I've never used it yet).

--
Gabriel Genellina

**Daniel Nogradi** · Feb 16 '07, 11:05 AM

Re: Approaches of interprocess communication

Supposing you have two separate processes running on the same box,

what approach would you suggest to communicate between those two
processes.
>
Let me list the ones I know of:
>
* Sockets
Advantage: Supported per se in nearly every programming language
without even the need to install additional packages
Disadvantage: Lot's of code to write, and it's kind of silly to
communicate via TCP/IP if the processes run on the same machine.
>
* Webservices
Advantage: Relatively easy to use, can work across different
languages
Disadvantage: Even more overhead on the TCP/IP side that simple
sockets, as really bulky SOAP messages need to be passed around.
>
* CORBA -- similar to webservices but more complicated to code.
>
* Shared memory
I don't know much about this subject.
>
Supposing both processes are written in Python, is there any other way
to achieve this? To me, shared memory sound the most suited approach.
But as said, I am still fuzzy in this area. Where can I find more
information on this subject?

Hi, if your requirements are sufficiently light then pylinda might be
an easy-to-use solution:

University of York

http://www-users.cs.york.ac.uk/~aw/pylinda/

A simple example is here:

University of York

http://www-users.cs.york.ac.uk/~aw/pylinda/beginner.html

HTH,
Daniel

**Ben Finney** · Feb 16 '07, 11:05 AM

Re: Approaches of interprocess communication

"exhuma.twn " <exhuma@gmail.c omwrites:

Supposing you have two separate processes running on the same box,
what approach would you suggest to communicate between those two
processes.
>
Let me list the ones I know of:
>
* Sockets
Advantage: Supported per se in nearly every programming language
without even the need to install additional packages

This would be my choice. But first, set up a well-defined *protocol*
(preferably based on text commands) for the two processes to use for
communication; don't have each of them being intricately aware of each
others' implementation.

Disadvantage: Lot's of code to write, and it's kind of silly to
communicate via TCP/IP if the processes run on the same machine.

You can cut down on the amount of code by using the standard library
"cmd" module to handle a command interface, hooking the stdin and
stdout of the commandline handler to the socket.

If you're already thinking about cooperating processes, you should
make them network-neutral anyway from the start.

Here's what _The Art of Unix Programming_ has to say on the topic of
text protocols:

<URL:http://www.catb.org/~esr/writings/taoup/html/ch05s01.html>

and IPC tactics for peer processes:

<URL:http://www.catb.org/~esr/writings/taoup/html/ch07s07.html>

--
\ "There are only two ways to live your life. One is as though |
`\ nothing is a miracle. The other is as if everything is." -- |
_o__) Albert Einstein |
Ben Finney

**Ben Finney** · Feb 16 '07, 11:15 AM

Re: Approaches of interprocess communication

"Gabriel Genellina" <gagsl-py@yahoo.com.ar writes:

(And I would expect that making a connection to "localhost" actually
does *not* go down up to the network card hardware layer, but I
don't know for real if this is the case or not).

It damned well better. That's the entire point of the loopback
interface: to get all the network layer code involved, but not to talk
on a physical network interface.

If a programmer decides on behalf of the user that "localhost" should
be treated specially, that programmer is making an error.

--
\ "If you can't beat them, arrange to have them beaten." -- |
`\ George Carlin |
_o__) |
Ben Finney

**Duncan Grisby** · Feb 16 '07, 12:45 PM

Re: Approaches of interprocess communication

In article <1171620696.577 982.283740@m58g 2000cwm.googleg roups.com>,
exhuma.twn <exhuma@gmail.c omwrote:

>Supposing you have two separate processes running on the same box,
>what approach would you suggest to communicate between those two
>processes.

[...]

>* Webservices
Advantage: Relatively easy to use, can work across different
>languages
Disadvantage: Even more overhead on the TCP/IP side that simple
>sockets, as really bulky SOAP messages need to be passed around.
>
>* CORBA -- similar to webservices but more complicated to code.

Lots of people say that, but I don't think it's true. Obviously as the
maintainer of a CORBA implementation I'm biased, but take a look at
some examples of code that implement SOAP clients and servers and
compare it to similar CORBA code. Especially in Python, the SOAP code
tends to be incredibly verbose and complex, and the CORBA code really
small and simple.

My recommendation would be that for simple communications where
performance isn't important use XML-RPC; for more complex cases where
performance is a bit more important but you don't need anything except
Python, use Pyro; for cases where performance is particularly
important and/or you need cross-language communications, use CORBA.

Cheers,

Duncan.

--
-- Duncan Grisby --
-- duncan@grisby.o rg --
-- http://www.grisby.org --

--
Posted via NewsDemon.com - Premium Uncensored Newsgroup Service
------->>>>>>http://www.NewsDem

**exhuma.twn** · Feb 16 '07, 01:15 PM

Re: Approaches of interprocess communication

On Feb 16, 1:33 pm, Duncan Grisby <duncan-n...@grisby.org wrote:

In article <1171620696.577 982.283...@m58g 2000cwm.googleg roups.com>,
>
exhuma.twn <exh...@gmail.c omwrote:

Supposing you have two separate processes running on the same box,
what approach would you suggest to communicate between those two
processes.

>
[...]
>

* Webservices
Advantage: Relatively easy to use, can work across different
languages
Disadvantage: Even more overhead on the TCP/IP side that simple
sockets, as really bulky SOAP messages need to be passed around.

>

* CORBA -- similar to webservices but more complicated to code.

>
Lots of people say that, but I don't think it's true. Obviously as the
maintainer of a CORBA implementation I'm biased, but take a look at
some examples of code that implement SOAP clients and servers and
compare it to similar CORBA code. Especially in Python, the SOAP code
tends to be incredibly verbose and complex, and the CORBA code really
small and simple.
>
My recommendation would be that for simple communications where
performance isn't important use XML-RPC; for more complex cases where
performance is a bit more important but you don't need anything except
Python, use Pyro; for cases where performance is particularly
important and/or you need cross-language communications, use CORBA.

Maybe this line of mine was a bit too condensed ;) I fully agree with
you on what you say about CORBA. It's just that for most people IDL
looks a bit out of place. Especially because it resembles C. But once
you actually wrote a few projects using CORBA, you actually begin to
see it's elegance ;)

I find Webservices "easier" as you can (although it's not
recommendable) leave out the WSDL part. And some implementations
actually generate the WSDL for you. But it's true, comparing WSDL and
IDL I'd rather write some IDL than WSDL ;)

But, returning back to topic, I first want to thank you all for your
input. I appreciate all the ideas. Especially the idea of using the
"cmd" module for sockets. That sound's very intriguing and I will very
likely play around with that. But also PYRO seems quite useful.

About "Linda": Am I right that it looks very similar to "JavaSpaces "?
If yes, are there any funcdamental differences between those two?

**Diez B. Roggisch** · Feb 16 '07, 01:25 PM

Re: Approaches of interprocess communication

Maybe this line of mine was a bit too condensed ;) I fully agree with

you on what you say about CORBA. It's just that for most people IDL
looks a bit out of place. Especially because it resembles C. But once
you actually wrote a few projects using CORBA, you actually begin to
see it's elegance ;)

It looks out of the place in comparison to what exactly? A WSDL-document?
You certainly me laugh hard on that....

I find Webservices "easier" as you can (although it's not
recommendable) leave out the WSDL part. And some implementations
actually generate the WSDL for you.

You can't leave WSDL out of SOAP, you can leave it out of XMLRPC. Which is
nice and easy, but lacks any contract whatsoever. Nothing I as a Pythoneer
care to much about, but some people bother.

And generating the WSDL works from what exactly? ah, Java-code for example,
using java2wsdl. Which has a striking resemblance to.... C. Funny....

But it's true, comparing WSDL and
IDL I'd rather write some IDL than WSDL ;)

So - you say that yourself, but still you previously claimed IDL looks
strange to the eye?

Diez

**Paul Boddie** · Feb 16 '07, 01:55 PM

Re: Approaches of interprocess communication

On 16 Feb, 14:16, "Diez B. Roggisch" <d...@nospam.we b.dewrote:

>
You can't leave WSDL out of SOAP

Yes you can, since they're two different things. What you probably
meant was that you can't leave WSDL out of "big architecture", W3C
standards-intensive Web services. Of course, RPC-style SOAP without
the contracts imposed by WSDL may remove some of the attractions for
some people (who really should consider CORBA, anyway), but then
there's always document-oriented SOAP, although if you don't want the
baggage associated with routing and other things, plain XML messaging
would be easier. And there's always XMPP if you want stuff like
routing and a standard that isn't undergoing apparently continuous
change.

Paul

**Diez B. Roggisch** · Feb 16 '07, 02:05 PM

Re: Approaches of interprocess communication

Paul Boddie wrote:

On 16 Feb, 14:16, "Diez B. Roggisch" <d...@nospam.we b.dewrote:

>>
>You can't leave WSDL out of SOAP

>
Yes you can, since they're two different things. What you probably
meant was that you can't leave WSDL out of "big architecture", W3C
standards-intensive Web services. Of course, RPC-style SOAP without
the contracts imposed by WSDL may remove some of the attractions for
some people (who really should consider CORBA, anyway), but then
there's always document-oriented SOAP, although if you don't want the
baggage associated with routing and other things, plain XML messaging
would be easier. And there's always XMPP if you want stuff like
routing and a standard that isn't undergoing apparently continuous
change.

Didn't know that. Yet I presume it is pretty awful to manually decompose and
compose the method invocations and parameter sets.

I've got no idea what document-orientied SOAP means either. Is that just
pushing XML-files over a protocol?

Diez

**Paul Boddie** · Feb 16 '07, 02:25 PM

Re: Approaches of interprocess communication

On 16 Feb, 14:53, "Diez B. Roggisch" <d...@nospam.we b.dewrote:

>

[XMPP, XML messaging]

Didn't know that. Yet I presume it is pretty awful to manually decompose and
compose the method invocations and parameter sets.

It depends on how well you like working with XML, I suppose.

I've got no idea what document-orientied SOAP means either. Is that just
pushing XML-files over a protocol?

As I understand it, yes, although you still have to put the payload
inside the usual SOAP boilerplate.

Paul

**Steve Holden** · Feb 16 '07, 03:05 PM

Re: Approaches of interprocess communication

Ben Finney wrote:

"Gabriel Genellina" <gagsl-py@yahoo.com.ar writes:
>

>(And I would expect that making a connection to "localhost" actually
>does *not* go down up to the network card hardware layer, but I
>don't know for real if this is the case or not).

>
It damned well better. That's the entire point of the loopback
interface: to get all the network layer code involved, but not to talk
on a physical network interface.
>
If a programmer decides on behalf of the user that "localhost" should
be treated specially, that programmer is making an error.
>

Inter-process TCP/IP communication between two processes on the same
host invariably uses the loopback interface (network 127.0.0.0).
According to standards, all addresses in that network space refer to the
local host, though 127.0.0.1 is conventionally used.

The transmit driver for the loopback interface receives a datagram from
the local network layer and immediately announces its reception back to
the local network layer.

regards
Steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://del.icio.us/steve.holden
Blog of Note: http://holdenweb.blogspot.com
See you at PyCon? http://us.pycon.org/TX2007

**Roman Yakovenko** · Feb 16 '07, 03:45 PM

Re: Reg Google Web Toolkit and Python

On 2/16/07, Shadab Sayani <shadabsayani@y ahoo.comwrote:

Hi ,
We have a project where I need to read files store
them in database in the backend.We have done this in
python.Now we decided to use Ajax technique for user
interface.For that we found that GWT is one of the
best toolkits.Now I got a doubt can I interface GWT
with python.

http://pyjamas.pyworks.org/ is the way to go.

--
Roman Yakovenko
C++ Python language binding

NameBright - Coming Soon

http://www.language-binding.net/

**Daniel Nogradi** · Feb 16 '07, 04:45 PM

Re: Approaches of interprocess communication

About "Linda": Am I right that it looks very similar to "JavaSpaces "?

If yes, are there any funcdamental differences between those two?

Yes, they are both linda implementations , but I have no idea what so
ever how they compare. A local java expert maybe?

**Steve Holden** · Feb 16 '07, 04:45 PM

Re: Reg Google Web Toolkit and Python

Shadab Sayani wrote:

Hi ,
We have a project where I need to read files store
them in database in the backend.We have done this in
python.Now we decided to use Ajax technique for user
interface.For that we found that GWT is one of the
best toolkits.Now I got a doubt can I interface GWT
with python.
Thanks ,
Shadab.
>
Send instant messages to your online friends http://uk.messenger.yahoo.com

Please note that you should not create a new conversation on a newsgroup
by editing a reply to an unrelated post - your comments are now threaded
along wiht "Approaches of Interprocess Communication", making them
unnecessarily hard to find and somewhat confusingly positioned.

regards
Steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://del.icio.us/steve.holden
Blog of Note: http://holdenweb.blogspot.com
See you at PyCon? http://us.pycon.org/TX2007

Approaches of interprocess communication

Approaches of interprocess communication

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment