[zeromq-dev] .NET port

Martin Sustrik sustrik at 250bpm.com
Sat Aug 6 09:46:32 CEST 2011


Hi Fil,


> This would mean the API would be quite different, and shaped around
> async/non-blocking .
>
> Now, is this really stupid? Should I be porting the above to native
> Windows C/C++ for performance, then binding into the .NET world?

The thing is that while I would love to see an alternative 
implementation of 0MQ semantics (what I call SP, see here: 
http://groups.google.com/group/sp-discuss-group) the amount of work 
invested in 0mq is 10+ manyears.

If you are going reimplement it in C#, you have to expect to invest 
approximately the same amount of work to the project.

On the other hand, you can use 0mq and wrap it, which is approx. a 1-2 
day exercise. Moreover, there are several C# bindings available, which 
makes the task even simpler.

> Dumb question: is the core of zmq C or C++?

It's in C++.

> I am thinking these are
> fundamental changes from the way the core library works, so I can't just
> wrap this in....

 > To be clear this is what I am looking at:
 >
 > - Full C++/CLI port (not bind)

A design decision, not an requirement.

 > - Client and server functionality

Provided by 0MQ today.

 > - No synchronous API's - just Task/IObservable from .NET 4.0

I am not familiar with these classes, however, re-actor style API is 
easy to build on top of 0MQ. There are several such projects around.

 > - Lots of Rx (Reactive Extensions) and Async CTP

Once again, I am not familiar with the technologies, but I guess the 
previous point applies here.

 > - Managed IO completion ports

This is a hard one. Can't be added by wrapping 0MQ, has to be done in 
the core. See a lot of discussion on the topic on 0mq mailing list.

 > - IPC (shared mem?), TCP and UDP

Once IOCP is in place, adding IPC shouldn't be that hard.

Martin



More information about the zeromq-dev mailing list