Regarding ZeroMQ in a desktop application on Windows talking to another process on the same machine, bear in mind that zmq_ipc is not supported (see zmq_ipc(7)). Or at least, that's the last I heard. This is because it's fundamentally impossible to implement anything like quite like select() or epoll() for named pipes in Windows. Just use zmq_tcp instead.
The same basic problem plagued the development of the select() implementation in Cygwin and its derivatives. They got round the problem by starting a thread for every non-socket file descriptor (i.e. named pipes, serial ports, etc) being selected, with each thread polling the HANDLE for whether any data had arrived (or whatever events were being set in select()). Not very efficient. Yeurk.
Proactor vs Reactor
Windows is proactor (which can do only proactor), everything else (*nix, VxWorks) is reactor (which can also be used to implement a proactor). The development of the boost.asio library for C++ was influenced by this, and is a proactor design as a result so that it could be run on Windows. RabbitMQ is proactor too.
ZeroMQ with zmq_poll() is reactor.
Proactor - you pro-actively start up an asynchronous routine to handle whatever turns up in the future.
Reactor - you react to the arrival of whatever has turned up by starting a synchronous call to whatever routine you wish to handle it knowing that it will complete very quickly because the data is already there.
The difference is key. In a proactor design, once you have started up that asynchronous routine to read a message, you cannot (easily) stop it or change it until it has done its thing. That is very annoying if you change your mind, for example as a result of reading some message from somewhere else.
Small caveat - Windows does support select() for network sockets (thus reactor programming is possible with network sockets, but only network sockets), and is the only reason why ZMQ is supported to any extent whatsoever on Windows.
Mixing ZMQ with Desktop Application Event Callbacks
Anyway, proactor means that Windows and C# fundamentally expects everything to be served by callbacks. This basically means you won't be using the zmq_poll() call to tell you if new messages have arrived if you also have callbacks handling GUI events. Instead you'd most likely be making asynchronous calls to zmq_revcmsg(). Trying to mix zmq_poll() in with callbacks is asking for trouble (you'd be blending proactor and reactor).
Message Formats
ZeroMQ and sockets both transfer bytes (as discrete messages with ZeroMQ, as a byte stream with sockets). One still has the challenge of deciding what the bytes mean to applications.
I can recommend using something like Google Protocol Buffers to serialise messages for transport by ZeroMQ. It's available for both C# and Java, but it doesn't demarcate message boundaries. Fortunately, ZeroMQ does. [Using GPB over a socket stream can be painful, you have to demarcate the message boundaries oneself]. So you can serialise a message to a buffer, hand the buffer over to ZeroMQ as a message, the recipient receives the message and knows for absolute certain that there is one single solitary GPB within. If you like you can use GPB's "oneof" to smuggle arbitrary message types across, which can be very liberating. You can accomplish the same with other serialisation technologies too of course, my personal favourite being ASN.1.
