[zeromq-dev] .NET port

Fil Mackay fil at pobox.com
Sun Aug 7 14:34:32 CEST 2011

On Sun, Aug 7, 2011 at 6:36 AM, Martin Sustrik <sustrik at 250bpm.com> wrote:

> - Would this be done on 3.0 exclusively?
> Depends on you. If you need to be interoperable with existing 0MQ/2.1
> applications, you better support 2.1 as well as 3.0. Otherwise, go for 3.0.

How stable is 3.0 - lots of bugs, not production ready? My inclination is to
go for 3.0... onward and upwards and all that.

>  - How would IPC work, would it be named pipes or shared memory? If the
>> latter, what technique would be used (ring buffer et al.)?
> I would start with named pipes. Once it's done -- which is not a trivial
> task -- you can experiment with shared memory. Note that even with shared
> memory you need some kind of notification mechanism, presumably named pipes,
> so the work on named pipes won't be lost.

OK I know how IOCP works - can you explain how the POSIX equivalent (what's
it called?) works, so I can understand the difference between the two? Does
it use any asynchronous actions, ie. notify me on data arrival, or is
everything blocking on some kind of recv() call? What are the central
classes that will be impacted in implementing IOCP?

Is the intention that IOCP would be used for client and server comms?
Normally on Windows you only use IOCP for high-performance server scenarios
where you want to break the 1-connection-per-thread limit.

Why are named pipes so much different/more difficult than TCP?

Named pipes would be pretty heavyweight/slow for shared memory notification,
I'd be looking at either (a) spinning on volatile variable for low-latency
scenarios, or (b) ManualResetEvent otherwise.

- Anyone here had experience with Disruptor - the relatively new high
>> performance producer-consumer (Java). I have a dream about this combined
>> with zmq.
> I've read the Disruptor whitepaper and my feeling is that optimisations
> used by Disruptor are either already in 0MQ, or the use cases they address
> (such as multiple writers to a queue) don't exist in 0MQ. In any case, feel
> free to replace 0MQ queue (pipe_t class) by Disruptor and see what
> performance improvement you can get. There's no licensing problem as Apache2
> project (Disruptor) can be used in GPL3 project (0MQ).

So, pipe_t (I'm learning the zmq lingo) is a single writer, many reader

Regards, Fil.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20110807/c0d27b8e/attachment.htm>

More information about the zeromq-dev mailing list