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?
On Sat, Apr 6, 2013 at 1:21 PM, mwpowellhtx <mwpowellhtx@...> wrote: > So... What's the story with the ZMQ / XS fork in the road? In either case, more work is involved, adapters are required around or among the mix of comm "pipes", whether we're talking about a file transfer chunker (per se), number crunching data factory producer/consumer, event brokering messaging system, what have you. XS is mostly dead, further development is being done from the ground up under the nanomsg project. Cheers, Dirkjan
On Sat, Apr 6, 2013 at 1:41 PM, mwpowellhtx <mwpowellhtx@...> wrote: > 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. I would definitely go with ZMQ over Crossroads until nanomsg is further along. Cheers, Dirkjan
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 directly into the object model allowing me to focus on the servant/client relationship, also instead of infrastructure. So... What's the story with the ZMQ / XS fork in the road? In either case, more work is involved, adapters are required around or among the mix of comm "pipes", whether we're talking about a file transfer chunker (per se), number crunching data factory producer/consumer, event brokering messaging system, what have you. Serialization issues can be addressed. As can SOLID architectural decisions like extending into a distributed event model, etc. The right kind of SOLID design can permit an extensible, maintainable design around either technology. As regards ZMQ or XS, I'm more concerned with the fork and stability of either or both infrastructures. I believe I've seen a post enumerating the ZMQ roadmap as well as XS. Along these lines... Also, are there any benchmark numbers comparing / contrasting latency and throughput outcomes?(Continue reading)
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...
― 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
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 would work correctly. In addition to this I've cleaned up the documentation building step: - Man files are now automatically handled by automake - I've fixed some issues that caused the XML/HTML documentation to be built when it didn't need to and often in an incomplete way - I've added quiet rules when invoking asciidoc that make the make invocation output more consistent As a final step I've fixed out-of-tree builds when using the included the openpgm library. Without these changes you would need to build libxs from within the source tree if you intended to use the included openpgm tarball as out-of-tree builds didn't work.(Continue reading)
― 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
― 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
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. ######################################################################
RSS Feed1 | |
|---|---|
9 | |
5 | |
3 | |
2 | |
12 | |
47 | |
11 | |
18 | |
200 | |
328 | |
412 |
