«

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.

* 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?

En Fri, 16 Feb 2007 07:11:36 -0300, exhuma.twn <> escribió:

> 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

> 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:

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

A simple example is here:

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

HTH,
Daniel

"exhuma.twn" <> writes:

> 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

"Gabriel Genellina" <gagsl-> 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

In article < .com>,
exhuma.twn <> wrote:

>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 --
-- --
-- http://www.grisby.org --

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

On Feb 16, 1:33 pm, Duncan Grisby <duncan-n...@grisby.org> wrote:
> In article <1171620696.577982.283...@m58g2000cwm.googlegroups .com>,
>
> exhuma.twn <exh...@gmail.com> wrote:
> >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?

> 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

On 16 Feb, 14:16, "Diez B. Roggisch" <d...@nospam.web.de> wrote:
>
> 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

Paul Boddie wrote:

> On 16 Feb, 14:16, "Diez B. Roggisch" <d...@nospam.web.de> wrote:
>>
>> 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