gmane.network.crossroads.devel

epgm example code

ismud — 2013-05-13T12:07:31

hi,

are there any working examples of using epgm transport with xs? I wrote an example program in C to use tcp, but the same program doesn't work with epgm. I'm not sure what's wrong, cause both programs (publisher and subscriber) seem to work fine, and I can also see packets on udp port using tcpdump, but messages aren't getting through (to the subscriber). I'm using PUB/SUB pattern.

Or anyone has some suggestions on what to look for to make it work?

Re: Custom Transports

Michael Powell — 2013-04-10T11:59:27

Hello,


On Wed, Apr 10, 2013 at 1:33 AM, Martin Sustrik <sustrik-8XN41Hm7QBXQT0dZR+AlfA< at >public.gmane.org> wrote:


It sounds like you've already got an RPC protocol at some level, which I am
assuming factors in the transport under the hood.

I don't know how your business has approached the issue, but I think of a
CORBA, WCF, or even ZeroC Ice, for instance. All strong candidates in their
own right, notwithstanding bloat, when you factor in the endpoint issues
are basically handled for you.

Much of the overhead over and above a "simple" message queue is in the
registration with a hub of some sort, marshaling of object methods and
addresses and so on, but RPC handles it for you: no reinventing the wheel.



See above. I would question why you need another TCP-anything. What's wrong
with the one you have? And plug into that framework. If you're looking at
RPC anyway and you've already got one, this is just one more endpoint,
object-over-the-wire to concern yourself with.

Anywho... Cheers.

Martin

Re: Custom Transports

Martin Sustrik — 2013-04-10T06:33:26

Hi Jason,


The question is how much effort are you willing to spend on this. 
Basically, adding a new transport is complex and time consuming. Also, 
given that you want to implement a proprietary protocol, you are not 
going to get help from outside.

I would suggest writing a internalRPC-TCP bridge instead of implementing 
a new transport.

Martin

Custom Transports

Jason Baker — 2013-04-09T22:07:01

What's involved in creating a transport for Crossroads IO/ZeroMQ?  I'm
trying to see if there's anything I can hack together to make Crossroads
play well with my company's internal RPC protocol.

Re: To ZMQ or to XS: ArchLinux ARM

mwpowellhtx — 2013-04-06T11:41:18

So what does this mean? Keep on with ZMQ for the time being, if distributed architecture is what we're aiming at accomplishing? Nanomsg is not yet released, so where does that leave us? Good to learn this before spending a whole lot of time on the topic.

Re: To ZMQ or to XS: ArchLinux ARM

Dirkjan Ochtman — 2013-04-06T11:35:41

XS is mostly dead, further development is being done from the ground
up under the nanomsg project.

Cheers,

Dirkjan

Re: To ZMQ or to XS: ArchLinux ARM

Dirkjan Ochtman — 2013-04-06T11:44:03

I would definitely go with ZMQ over Crossroads until nanomsg is further along.

Cheers,

Dirkjan

To ZMQ or to XS: ArchLinux ARM

mwpowellhtx — 2013-04-06T11:21:06

Hello,

See below: I'm less concerned the cross-language support is there, looks like enough work is put into C# .NET, could be used there as well as C++. Our 64 million dollar question is: has anyone cross compiled into ArchLinux ARM yet?

I am responsible for designing an embedded device which I believe will have embedded and non-embedded, intra-process, and inter-process, messages passing between various architectural components, and several potentially viable technologies have revealed themselves as candidates in this horse race.

While I don't consider myself a betting man, per se, I would like to leverage this technology for infrastructure so that I can focus on solving present problems instead of bogging down in inter-thread comm, event brokering, IPC, and a whole host of related issues.

Also, to give you an idea, CORBA and ZeroC Ice have also been considered. CORBA less attractive for bloat, design-by-committee reasons, and ZeroC Ice has its own set of challenges: technically, is very fast, extends

Re: To ZMQ or to XS: ArchLinux ARM

mwpowellhtx — 2013-04-06T12:15:06

Pretty much the only conclusion I can reach as well. Very good. Thank ye sir.

Re: To ZMQ or to XS: ArchLinux ARM

mwpowellhtx — 2013-04-06T11:28:31

Looks like the libraries are at least there in some form.

http://archlinuxarm.org/packages?arch=&search=&order=pkgname&sort=desc

So I could possibly dynamically link with a shared library. Which answers one question, can build from sources. I'd like to configure and build statically however. Possible?

Does anyone know who's pushing the ArchLinux ARM cross compile library into the mirrors? Simple to ./configure, make, make install to a local $WORKSPACE/tools/installed directory?

Thank you...

Re: [PATCH 0/3] Streamline the build system and convert it to to non-recursive automake

Martin Sustrik — 2013-02-13T06:35:59

Hi Gabriele,


Thanks for the patches! They are applied to the mainline now.

Martin

[PATCH 2/3] Reworked the rules to build the manpages and extra documentation

Gabriele Svelto — 2013-02-12T15:49:08

― Attachment links are at the end of this email ―
Crossroads Development now contains the following file

    http://groups.crossroads.io/r/file/wIRyuUxPOzbBBWrGGrOByQ1pIw5-12p-2owxBZ6
    Name: 
    Type: text/x-patch
    Size: 3KB

[PATCH 0/3] Streamline the build system and convert it to to non-recursive automake

Gabriele Svelto — 2013-02-12T15:47:54

  Hello all,
I've been sitting for a while on a bunch of patches I wanted to sumbit 
to complete the build system clean up I had been working on and I 
thought it would be high time to submit them.

I've cooked up a set of 3 patches that converts the build system to 
non-recursive automake. This essentially consolidates the build system 
in a single makefile speeding up builds and tests quite a bit as all 
independent targets can now be built/run in parallel even though they 
reside in different sub-directories. In addition to that, all targets 
now have explicit dependencies even across sub-directories so for 
example changing a header file will automatically cause tests using it 
to be rebuilt which was not the case before. The only downside of this 
is that the main Makefile is quite a bit larger than before (but 
organized on a per-subdirectory basis) and rules are longer. All targets 
however are built exactly as they were before; I've also tested the 
patches on multiple architectures to ensure they wo

[PATCH 3/3] Fixed out-of-tree builds when using the included openpgm library

Gabriele Svelto — 2013-02-12T15:49:27

― Attachment links are at the end of this email ―
Crossroads Development now contains the following file

    http://groups.crossroads.io/r/file/3AG7G22bGRCpS6L3CfCyvDaKvvP-Hj-2owxdbs
    Name: 
    Type: text/x-patch
    Size: 2KB

[PATCH 1/3] Converted the build system to non-recursive automake

Gabriele Svelto — 2013-02-12T15:48:42

― Attachment links are at the end of this email ―
Crossroads Development now contains the following file

    http://groups.crossroads.io/r/file/c0kBkvizy6AJkXbXwFWp4Tyfrnv-7eR-2owxc6l
    Name: 
    Type: text/x-patch
    Size: 27KB

Re: wire protocol

Doherty, Kevin — 2012-12-11T12:42:45

Tx Martin,
Here is some rough and ready tracing of a PUSH publisher
Followed by a PULL subscriber.
Note the hex 17e in the exchange.

Basically I'm trying to use JeroMq for Windows
But it does not talk to xs 1.1    while being fine with 0MQ 2.2 ? (the trace below)
Tx++


Publisher->
process_command for 1
zmq::zmq_init_t::process_plug calling plug :zmq_engine_t::plug calling io_object_t::plug
zmq::io_object_t::io_object_t   plug
:zmq_engine_t::plug after calling io_object_t::plug plug calling in_eventin in_event after in_event sleep in get_buffer
insize=0
read end
push data to decoder
in process_buffer
inout flush
no error
after plug in_eventprocess_command for 2 before deallocate after deallocate after deallocate
outsize=2
17ewrite end2
in in_event
after in_event sleep
in get_buffer
insize=2
17e^A~read end
push data to decoder
in process_buffer
one byte ready
in next_step
flags ready
in next_step
message_ready




Subscriber ->
process_command for 1
zmq::zmq_init_t::process_plug calling plug :zmq_engine_t::p

Re: wire protocol

Martin Sustrik — 2012-12-11T12:05:37


What's that? Doesn't look like something printed by XS or 0MQ itself.

Martin

Re: wire protocol

Doherty, Kevin — 2012-12-10T22:52:10

Folks,
In an effort to get some comms going with xs1.1
I first  traced zmq 2.2 and notice the following in a PUSH/PULL handshake
Coming from both sides of the communication.
Where is it coming from ? tx
   
in_event sleep
in get_buffer
insize=2
17e     
ETB(end of tran) and SO (shift out)
push data to decoder

######################################################################
The information contained in this communication is confidential and
may contain information that is privileged or exempt from disclosure
under applicable law. If you are not a named addressee, please notify
the sender immediately and delete this email from your system.
If you have received this communication, and are not a named
recipient, you are hereby notified that any dissemination,
distribution or copying of this communication is strictly prohibited.
######################################################################

Re: lua binding

Martin Sustrik — 2012-11-16T09:20:56


You can use the zeromq lua binding via zeromq compatibility layer.

Martin

lua binding

fabien.imbault — 2012-11-15T23:31:09

Hi,
do you plan a lua binding ?
thxs
fabien

Re: Crossroads IO vs ...

Schmurfy — 2012-10-26T14:31:29

Here is the patch: https://gist.github.com/3958827
I certify the code is released under MIT license.

I Added a Mac OS X implementation for the sp_clock_time() function since
CLOCK_MONOTONIC does not exists and removed one compiler flag
when compiling under Mac OS X (-lrt).

I am not sure about thread safety with the static variable though.

On 22 October 2012 17:04, Schmurfy <schmurfy-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote: