Maybe this can be wrapped to just plug it into where IPC sits on real operating systems.
^5
Sven
---------------------------------------------------------
E = mc² ± 2dBA ----- everything is relative
---------------------------------------------------------
-----Original Message-----
Date: Tue, 30 Nov 2010 06:05:21 +0100
Subject: [zeromq-dev] IPC on Windows (again)
From: Marcelo Cantos <marcelo.can...@gmail.com>
To: ZeroMQ development list <zeromq-dev@lists.zeromq.org>
2010/10/28 Mikael Helbo Kjær <m...@designtech.dk>
... I could really use an IPC solution for Windows. ...
I would love to see this too. I understand that the
problems with implementing IPC on Windows are significant, so I am
trying to decide between several options:
- Use tcp:// with fixed port allocations. But how do we allocate ports safely when writing software for consumer PCs?
- Use tcp:// with dynamic port allocations. I'm not sure this is even possible, since zmq_connect may be called before zmq_bind.
- Implement ipc:// properly on Windows. This sounds like a lot of work, which I don't mind so much. But how difficult will it be to get it right?
- Fudge ipc:// by using tpc:// with dynamic port allocations behind the scenes. Is this an easier path to follow, perhaps?
None of these
options is particularly palatable, so I'm wondering whether anyone else
has gone down this or some other path, and what measure of success
they've had.
Finally, I get that it's really
hard, but I will say this: If we had IPC on consumer-grade desktop
machines (which mostly run Windows), this might profoundly impact on the
way consumer software is written. By way of illustration, one
mini-project I have in mind is to slice TortoiseSVN, TortoiseHg, etc.
down the middle into two parts. A DLL lives in Windows explorer and has
no functionality other than to forward events such as a right-clicks and
menu selections to a background service and take instructions from the
service on how to behave (create/delete menus, present dialog boxes,
etc.). Since the DLL would almost never need to be upgraded, this would
largely eliminate the frequent rebooting that plagues anyone who tries
to keep their version of TortoiseXXX up to date. ZeroMQ would be the
perfect asynchronous communication medium between the DLL and the
service, and would even allow seamless upgrade and service cut-over
while the UI is still up. One could also instrument and monitor the
application, without changing code, by interposing a logging proxy
between the two components. Obviously, the same model could be applied
to any shell-extension, since they are all subject to the pain of
reboots when upgrading. This might even lead to a universal
shell-extension protocol that thoroughly reinvigorates the scene as
developers can now write shell extensions in Python or Ruby or whatever.
And it goes without saying that in some cases these services could run
on a different host. Imagine right-clicking an MP3 file on your notebook
PC and having your home media appliance with the wicked sub-woofers
offer to play it for you. Of course, this is possible now via tcp://,
but the framework itself will never happen if ZeroMQ doesn't do ipc://
on Windows one way or another.
Cheers,
Marcelo
_______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
