Page 1 of 1

Interprocess Communication

Posted: Mon Jun 30, 2014 8:43 pm
by StephenC
My app is split into client and server processes that both run on the local machine (the server component manages audio streaming output) and I am exploring how they would communicate when I port to wxWidgets.

I note that the recommended method for IPC on wxWidgets is to use sockets
http://docs.wxwidgets.org/trunk/overview_ipc.html

However, there seem to be non-trivial drawbacks with this, such as trying to find a guaranteed free port, and also triggering alerts or being blocked by a firewall, even on the localhost.

I will never need remote IPC, so I would prefer to use something with less overhead, in particular I'm thinking of either named pipes, or memory-mapped files.

Both of these are supported by Windows and (presumably all flavours of) Unix. How does wxWdigets offer platform-independent access to these functions?

Re: Interprocess Communication

Posted: Mon Jun 30, 2014 8:56 pm
by doublemax
in particular I'm thinking of either named pipes, or memory-mapped files.

Both of these are supported by Windows and (presumably all flavours of) Unix. How does wxWdigets offer platform-independent access to these functions?
It doesn't.

Maybe boost memory mapped files could be an alternative.

Re: Interprocess Communication

Posted: Mon Jun 30, 2014 9:10 pm
by StephenC
Thanks dm. Is this something that has ever been raised by others?

I'm mostly interested in supporting Windows and OSX, so if I wanted to use named pipes or memory-mapped files, would it be a reasonable thing then to have #ifdef sections that switch in the native code of these two platforms?

If so, I'd be happy to contribute that code as a starting point for official wx support of these areas. But I'm aware of course that many other platforms need to be considered and supported than just my two (although I would imagine most versions of Unix would be similar to OSX?)

How does the assessment and contribution process work for expanding wx into new areas?

Re: Interprocess Communication

Posted: Mon Jun 30, 2014 9:27 pm
by doublemax
Please start a discussion about this at the #wx-dev mailing list, where you can reach the core wx developers, this is a user forum.
https://groups.google.com/forum/#!forum/wx-dev

Re: Interprocess Communication

Posted: Mon Jun 30, 2014 10:48 pm
by StephenC
Thanks, yes I will make contact there in due course. At the moment I'm still just trying to get a sense of how the wx project evolves in general.

BTW, are you sure there is no support for named pipes already? I found a previous thread on named pipes
http://forums.wxwidgets.org/viewtopic.php?f=1&t=14336

It seems indicate some support via wxFile is available, due to the existing identifier wxFILE_KIND_PIPE. Any thoughts on this?

Re: Interprocess Communication

Posted: Mon Jun 30, 2014 11:04 pm
by doublemax
It seems indicate some support via wxFile is available, due to the existing identifier wxFILE_KIND_PIPE. Any thoughts on this?
Sorry, i just don't know.

Re: Interprocess Communication

Posted: Tue Jul 01, 2014 12:47 am
by StephenC
No sweat, thanks anyway. I'll look closer into the source.

Re: Interprocess Communication

Posted: Tue Jul 01, 2014 1:36 pm
by T-Rex
http://docs.wxwidgets.org/trunk/classwx_connection.html

As far as I remember, there is a HTML Help viewer app in `utils` in wxWidgets distro and it was using the same approach. You can try to use it as a reference.

Re: Interprocess Communication

Posted: Wed Jul 02, 2014 1:31 am
by StephenC
I've studied the source and just for future reference, here's my findings:

wxFile does define a wxFILE_KIND_PIPE for the wxGetFileKind function, but it applies only to __WINDOWS__ and __UNIX__ and is used primarily to determine whether the file is seekable or not (since in these cases, pipes are implemented as files, and therefore could be masquerading as one).

Quoting from /common/filefn.cpp (Line 1852)

// Some file types on some platforms seem seekable but in fact are not.
// The main use of this function is to allow such cases to be detected
// (IsSeekable() is implemented as wxGetFileKind() == wxFILE_KIND_DISK).

But wxWidgets does not yet contain any of the functions actually needed to operate a named pipe at this stage.

Anyway this is good to know and I hope it helps someone else. For myself, I am not yet migrating my app to wxWidgets, but I am concluding that named pipes are the best solution for my application.

So I am going to go ahead with my native Windows version of named pipes now, and when I start my port across in a few month's time, I will have to look at it again.

If there is interest in extending wx in this direction in future, let me know, I will be happy to be involved with the Windows and possibly OSX implementations.

Thanks for the comments.

Re: Interprocess Communication

Posted: Mon Jul 07, 2014 6:28 am
by eranif
If you are still looking for IPC, I have written a small wrapper around ZeroMQ which can be found here:

https://github.com/eranif/ZeroMQCxxAPI

here is how a client code looks like:

https://github.com/eranif/ZeroMQCxxAPI/ ... r/main.cpp

And the server code:
https://github.com/eranif/ZeroMQCxxAPI/ ... r/main.cpp

Eran