Interprocess Communication
Interprocess Communication
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?
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
It doesn't.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?
Maybe boost memory mapped files could be an alternative.
Use the source, Luke!
Re: Interprocess Communication
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?
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
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
https://groups.google.com/forum/#!forum/wx-dev
Use the source, Luke!
Re: Interprocess Communication
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?
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
Sorry, i just don't know.It seems indicate some support via wxFile is available, due to the existing identifier wxFILE_KIND_PIPE. Any thoughts on this?
Use the source, Luke!
Re: Interprocess Communication
No sweat, thanks anyway. I'll look closer into the source.
- T-Rex
- Moderator
- Posts: 1248
- Joined: Sat Oct 23, 2004 9:58 am
- Location: Zaporizhzhya, Ukraine
- Contact:
Re: Interprocess Communication
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.
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
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.
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
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
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