ZeroMQ - Forum - OpenEdge Development - Progress Community
 Forum

ZeroMQ

  • http://www.zeromq.org/

    has anyone played with this in ABL ?

    Looks *really* interesting

  • has anyone played with this in ABL ?

    Looks *really* interesting

    Now I did :-)

    The clrzmq2 .NET bindings work fine in 10.2B. Must say it looks very cool for IPC

    Did you already look into using a Unix build on Linux or so?

  • I have been looking at the c / ruby bindings on linux.

    What I really want to be able to do is to have an ABL version so

    that we can run this on windows and linux , gui and char, webspeed and

    appserver

    How complicated are the clrzmq2 bindings ?

  • How complicated are the clrzmq2 bindings ?

    Easy!

  • care to share ?

  • care to share ?

    Can be done. I basically translated the C# weather info pub/sub sample into ABL.

    Let me get back to a computer tonight.

  • Another interesting thing would be creating ABL bindings around the C++/C core API, similarly to what the C#/Mono code does. That would be more platform-agnostic than using the C# classes.

    The C# classes like ZMQ+C (ie the C internal class in ZMQ) does a bunch of thigs like

      [DllImport("libzmq", CallingConvention = CallingConvention.Cdecl)]

            public static extern IntPtr zmq_init(int io_threads);

    which we can duplicate in ABL quite easily along the lines of ...

    PROCEDURE zmq_init EXTERNAL "libzmq.dll" CDECL

      DEFINE INPUT PARAMETER io_threads AS INT.
      DEFINE RETURN PARAMETER result AS LONG. /*? not sure of types here, coded in PSDN editor */
    END.

    One (big) question is whether the C# bindings are multi-threaded, or whether that's dealt with in the core API.

    -- peter

  • that's what I meant about the ABL version ..

  • Ok, here's some code. I just played with the stuff for 30 minutes this afternoon and basically still don't understand how it's working...

    The samples are based on this:

    Publisher code: http://zguide.zeromq.org/cs:wuserver

    Subscribed code: http://zguide.zeromq.org/cs:msreader

    As you'll see the subscriber will poll for messages. It's a pub/sub pattern. You can launch the receiver twice and each receiver will get every message - and that appears to be in order. You can quit the publisher and start it again. It's an interestign concept - there is not broker but still as long as there is a single subscriber the messages aren't getting lost.

    The code is attached, the Assemblies are in the Assemblies folder, so start it with -assemblies Assemblies

    The actual 0MQ implementation (my own compilation) is in libzmq.dll and I assume that needs to be in the working directory, DLC/bin or system32, right?

    When writing the code, the biggest challenge was to turn a .NET Char[] into a Stirng or CHARACTER (without looping thru it). In C#, I'd NEW a System.String and pass the Char[] as a parameter. ABL's attempt to automatically map System.String to CHARACTER and disallow the use of System.String forced me to use reflection for that purpose. That makes the code look long and complicated. Any alternative to that is welcome...!

    Once I understand more about 0MQ and the .NET API I can try to replace the polling with a real event. The seems to be a "Device" concept that uses delegates for callbacks and that should allow to turn that into a real .NET event.

  • Actually for most of my use cases I could live with the .NET based 0MQ implementation.

    At the typical use cases for interprocess communication that typically involve Unix/Linux the AppServer can be used or actually Sonic MQ for more flexible communication. I am (maybe was) looking for a simple way of communication on a single client machine. I was actually already looking for MSMQ for that purpose. But that fact that I didn't find an easy to automate setup for MSMQ kept me from going that direction.

    The charme of 0MQ is that is does not need a broker and all I need are two or three dll files that need to be copied to the client (as part of the R-Code distribution).

    Basically for all those cases to keep the UI responsive (yeah, the lack of multi-threading) this is qoing to help (responsive splash screens, background printing, etc., data export, import from local applications, ...). I guess this will also help with telefony. When the phone rings we won't miss the caller's number just because the client is busy.

  • thanks for this, Mike.

    I'll have a look.

    Julian

  • Hi Guys,

    I realise this pose is old, but i'm just starting to look at Progress and ZeroMQ. Have you been able to implement ok? if so is there any code I could look at?

    Rod