[zeromq-dev] IPC on Windows (again)
Marcelo Cantos
marcelo.cantos at gmail.com
Tue Nov 30 06:05:21 CET 2010
2010/10/28 Mikael Helbo Kjær <mhk at 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:
1. Use tcp:// with fixed port allocations. But how do we allocate ports
safely when writing software for consumer PCs?
2. Use tcp:// with dynamic port allocations. I'm not sure this is even
possible, since zmq_connect may be called before zmq_bind.
3. 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?
4. 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20101130/edac8826/attachment.htm>
More information about the zeromq-dev
mailing list