[zeromq-dev] IPC on Windows (again)

Martin Sustrik sustrik at 250bpm.com
Thu Dec 2 20:44:26 CET 2010

On 11/30/2010 03:51 PM, Martin Lucina wrote:
> marcelo.cantos at gmail.com said:
>> 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?
> Option 4) seems easy at first sight but you still have the problem of
> naming; IPC naming in 0MQ uses a string (well, on *NIX technically a
> filesystem path) for the endpoint. It's not at all clear how you would
> translate that to the correct dynamically allocated port.
> Option 3) is the ultimate goal but is a lot of work and back when we
> discussed this it was not clear at all if there's an official Win32 API for
> IPC which we can integrate into a standard
> select()/WSAEventSelect()/IOCP-based poller on Windows.
> I did mention LPC at the time which looks like it might work but is
> for all intents and purposes an undocumented API with all the dangers that
> entails.
> Option 2) would work if we finally get around to allowing zmq_bind() to a
> dynamically allocated port. That is something for a future release post
> 2.1.

1. Would work. The ports would have to be fixed at development time, 
while leaving option to overload the port number on client site if it 
clashes with some other program.

2. It's not possible, because if you start the connecting peer first you 
don't know what the port number will be when the binding peer starts and 
thus you cannot specify what port to connect to.

3. The only real solution. Lot of technical problems related to WinAPI 
peculiarities to be solved though. See mato's discussion of the problem 

4. Same as 2.


More information about the zeromq-dev mailing list