www.beepcore.org 'BEEP is not a protocol for sending and receiving data directly. Rather, it allows you to define your application protocol on top of it, reusing several mechanisms such as: asynchronous communications, transport layer security, peer authentication, channel multiplexing on the same connection, message framing, channel bandwidth management, and many more interesting network features.' jordan ash // cto noospheer // noo corp
On Wed, Nov 23, 2011 at 3:30 AM, <[email protected]>wrote: > Send zeromq-dev mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of zeromq-dev digest..." > > > Today's Topics: > > 1. 3.1 problem with DIEALER-ROUTER pair. (Alexander Altshuler) > 2. [PATCH] ENOTCONN on recv() on TCP socket treated decently > (Martin Sustrik) > 3. Introducing leveldb-server using zmq and pyzmq (Srini Kommoori) > 4. Re: Introducing leveldb-server using zmq and pyzmq (Ian Barber) > 5. Re: Introducing leveldb-server using zmq and pyzmq > (Pieter Hintjens) > 6. Re: The Clone Pattern (Pieter Hintjens) > 7. Re: 3.1 problem with DIEALER-ROUTER pair. (Pieter Hintjens) > 8. Re: [PATCH] MSVC10 project files (Stuart Webster) > 9. 0MQ on embedded devices - Quadrocopter project > ([email protected]) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 22 Nov 2011 14:37:09 +0300 > From: "Alexander Altshuler" <[email protected]> > Subject: [zeromq-dev] 3.1 problem with DIEALER-ROUTER pair. > To: "'ZeroMQ development list'" <[email protected]> > Message-ID: <000001cca90b$122a53c0$0900a8c0@development> > Content-Type: text/plain; charset="us-ascii" > > Hi > > At the bottom of this message you may find a simple test program for > DEALER<->ROUTER socket pair. > It sends test message from dealer to router and then back. > It works fine with 3.0.x, but with 3.1 HEAD blocks on second > zmq_recvmsg() ,please see inline comment. > > My test platform Win7, build target - Win32/Debug. > > Is something changed in DEALER-ROUTER behavior or it is just a bug?! > > Regards > Alexander > > > #include "zmq.h" > > int main(int argc, char* argv[]) > { > void* context1 = zmq_init( 1 ); > void* dealer = zmq_socket( context1, ZMQ_DEALER ); > zmq_connect( dealer, "tcp://127.0.0.1:5555" ); > > void* context2 = zmq_init( 1 ); > void* router = zmq_socket( context2, ZMQ_ROUTER ); > zmq_bind( router, "tcp://*:5555" ); > { > zmq_msg_t msg; > zmq_msg_init_size( &msg, 16 ); > memset( zmq_msg_data( &msg ), 1, 16 ); > zmq_sendmsg( dealer, &msg, 0 ); > zmq_msg_close( &msg ); > } > zmq_pollitem_t items [] = > { > { router, 0, ZMQ_POLLIN, 0 } > }; > zmq_poll( items, 1, 1500 ); > if( items [0].revents & ZMQ_POLLIN ) > { > zmq_msg_t msg; > > // first message should be "reply-address" > zmq_msg_init( &msg ); > zmq_recvmsg( router, &msg, 0 ); > size_t size = zmq_msg_size( &msg ); > zmq_sendmsg( router, &msg, ZMQ_SNDMORE ); > zmq_msg_close( &msg ); > > // we always expect second message immediately > zmq_msg_init( &msg ); > zmq_recvmsg( router, &msg, 0 ); // blocked here!! > zmq_msg_close( &msg ); > zmq_msg_init_size( &msg, 16 ); > memset( zmq_msg_data( &msg ), 2, 16 ); > zmq_sendmsg( router, &msg, 0 ); > zmq_msg_close( &msg ); > } > { > zmq_pollitem_t items [] = > { > { dealer, 0, ZMQ_POLLIN, 0 } > }; > zmq_poll( items, 1, 1500 ); > if( items [0].revents & ZMQ_POLLIN ) > { > zmq_msg_t msg; > zmq_msg_init( &msg ); > zmq_recvmsg( dealer, &msg, 0 ); > zmq_msg_close( &msg ); > } > } > zmq_close( dealer ); > zmq_close( router ); > > zmq_term( context1 ); > zmq_term( context2 ); > > } > > > > ------------------------------ > > Message: 2 > Date: Tue, 22 Nov 2011 14:50:18 +0100 > From: Martin Sustrik <[email protected]> > Subject: [zeromq-dev] [PATCH] ENOTCONN on recv() on TCP socket treated > decently > To: "[email protected]" <[email protected]> > Message-ID: <[email protected]> > Content-Type: text/plain; charset="iso-8859-1" > > > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: 0001-ENOTCONN-on-recv-on-TCP-socket-is-treated-decently-i.patch > Type: text/x-diff > Size: 911 bytes > Desc: not available > Url : > http://lists.zeromq.org/pipermail/zeromq-dev/attachments/20111122/3a5bc0eb/attachment-0001.patch > > ------------------------------ > > Message: 3 > Date: Tue, 22 Nov 2011 06:26:11 -0800 > From: Srini Kommoori <[email protected]> > Subject: [zeromq-dev] Introducing leveldb-server using zmq and pyzmq > To: ZeroMQ development list <[email protected]> > Message-ID: > <CAG_nbntzeiZqUXdPt7h4zYEy=7HCYtrzmWY67CJ3jm-1o_Oi=q...@mail.gmail.com > > > Content-Type: text/plain; charset="utf-8" > > I just pushed leveldb-server using zmq and pyzmq > https://github.com/srinikom/leveldb-server > > Appreciate feedback/comments. There is a known issue from zmq side with 1M+ > messages that I am looking at. Planning to leverage lot of zmq topologies > and features. > > thanks, > -Srini > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://lists.zeromq.org/pipermail/zeromq-dev/attachments/20111122/2894c1e8/attachment-0001.htm > > ------------------------------ > > Message: 4 > Date: Tue, 22 Nov 2011 14:32:26 +0000 > From: Ian Barber <[email protected]> > Subject: Re: [zeromq-dev] Introducing leveldb-server using zmq and > pyzmq > To: ZeroMQ development list <[email protected]> > Message-ID: > <caeynewh7gwo63cvwhxo8r0dfmo1usgsaafoideci_cyscm2...@mail.gmail.com > > > Content-Type: text/plain; charset=ISO-8859-1 > > On Tue, Nov 22, 2011 at 2:26 PM, Srini Kommoori <[email protected]> wrote: > > I just pushed leveldb-server?using zmq and > > pyzmq??https://github.com/srinikom/leveldb-server > > Appreciate feedback/comments. There is a known issue from zmq side with > 1M+ > > messages that I am looking at. Planning to leverage lot of zmq topologies > > and features. > > thanks, > > -Srini > > Very nice, using zmq as the transport with leveldb seems like a very > good fit. Given the simplicity of the protocol, I would try > documenting it on a wiki page on github or similar to make it easier > for people to write clients. For your xreq/xrep queue you may want to > use on the built in device instead - nothing with your code looks > wrong, but it will limit any changes you have to make in version > changes I would suspect. > > Ian > > > ------------------------------ > > Message: 5 > Date: Tue, 22 Nov 2011 10:05:51 -0600 > From: Pieter Hintjens <[email protected]> > Subject: Re: [zeromq-dev] Introducing leveldb-server using zmq and > pyzmq > To: ZeroMQ development list <[email protected]> > Message-ID: > <CADL5_sjwSSUPyhnwoHFkeQzysxoeWeqX0Tau=bwvbps11at...@mail.gmail.com > > > Content-Type: text/plain; charset=ISO-8859-1 > > Srini, > > Nice work... > > On Tue, Nov 22, 2011 at 8:26 AM, Srini Kommoori <[email protected]> wrote: > > I just pushed leveldb-server?using zmq and > > pyzmq??https://github.com/srinikom/leveldb-server > > Appreciate feedback/comments. There is a known issue from zmq side with > 1M+ > > messages that I am looking at. Planning to leverage lot of zmq topologies > > and features. > > thanks, > > -Srini > > _______________________________________________ > > zeromq-dev mailing list > > [email protected] > > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > > > > > > ------------------------------ > > Message: 6 > Date: Tue, 22 Nov 2011 10:35:19 -0600 > From: Pieter Hintjens <[email protected]> > Subject: Re: [zeromq-dev] The Clone Pattern > To: ZeroMQ development list <[email protected]> > Message-ID: > <cadl5_si1laydobmd-rgotymsmjptthdsk5zgbrys0+uf9hu...@mail.gmail.com > > > Content-Type: text/plain; charset=ISO-8859-1 > > On Mon, Nov 21, 2011 at 11:15 PM, Tom Bennett > <[email protected]> wrote: > > > There is however one problem. If the intermediary cache server crashes > and > > restarts, I am not sure how I can recover it. There are several problems: > > Well, there is a design for this: http://zguide.zeromq.org/page:all#toc97 > > It uses the Binary Star pattern to create a primary-secondary backup > pair of intermediate servers. As long as they don't both crash, you'll > be fine. (So, they must run on different boxes, at least.) > > Downside: it is non-trivial. > > -Pieter > > > ------------------------------ > > Message: 7 > Date: Tue, 22 Nov 2011 11:58:49 -0600 > From: Pieter Hintjens <[email protected]> > Subject: Re: [zeromq-dev] 3.1 problem with DIEALER-ROUTER pair. > To: ZeroMQ development list <[email protected]> > Message-ID: > <cadl5_shlykpy7gi7ppjvmkpjthcy7mltnb9kvmlbkerebky...@mail.gmail.com > > > Content-Type: text/plain; charset=ISO-8859-1 > > On Tue, Nov 22, 2011 at 5:37 AM, Alexander Altshuler <[email protected]> > wrote: > > > At the bottom of this message you may find a simple test program for > > DEALER<->ROUTER socket pair. > > It sends test message from dealer to router and then back. > > It works fine with 3.0.x, but with 3.1 HEAD blocks on second > > zmq_recvmsg() ,please see inline comment. > > There is IMO a timing issue; the program sometimes blocks and sometimes > works. > > -Pieter > > > ------------------------------ > > Message: 8 > Date: Wed, 23 Nov 2011 02:27:42 +0100 > From: Stuart Webster <[email protected]> > Subject: Re: [zeromq-dev] [PATCH] MSVC10 project files > To: ZeroMQ development list <[email protected]> > Message-ID: <[email protected]> > Content-Type: text/plain; charset="ISO-8859-1"; format=flowed > > There's good news and bad news. > > First, the good news is that the implicit dependency that Andreas > mentioned can be avoided by specifying "set(CMAKE_SUPPRESS_REGENERATION > 1)" in CMakeLists.txt. The default behaviour is for cmake to add a > pre-build step that will regenerate Visual Studio projects if it detects > any changes in the CMakeFiles subdirectory of their build folder, but I > verified that this step was absent from the libzmq project generated > from Steve-o's CMakeList.txt after adding this flag. > > The bad news is that this deployment model isn't officially supported by > the cmake developers, who caution against doing this. They actually > recommend bundling cmake with your CMakeList.txt file(s) instead: > http://www.mail-archive.com/[email protected]/msg16634.html > http://www.mail-archive.com/[email protected]/msg12692.html > > Cross-generating MSVC project files from other operating systems is not > possible, so you would need to generate them on a Windows build machine: > http://www.mail-archive.com/[email protected]/msg12736.html > > One thing to be aware of is that the current release (2.8.6) has a bug > in which it always specifies absolute paths of source files in generated > MSVC project files, even if you specify relative paths > ("set(CMAKE_USE_RELATIVE_PATHS 1)") in your make file. That means that > we would be restricted to using an unsupported older release: > http://www.mail-archive.com/[email protected]/msg39143.html > > Lastly, generating projects that target both 32- and 64-bit platforms is > not possible either, so you would have to generate a separate project / > solution for 64-bit builds: > http://www.mail-archive.com/[email protected]/msg38787.html > > I was planning to extend the project in my original patch to support the > Intel compiler as well (it can use the unpatched C99 openpgm code and > generates faster binaries, but that's a topic for another day). It would > be unfeasible to provide that support if it meant doubling the number of > solutions shipped with the source code, but it looks like it would be > easy enough to add to the CMakeLists.txt file. > > In summary, it is possible to use cmake to generate MSVC project files > that have no dependencies on cmake itself. However, that's not what it > is designed to do, we would have to use an old version to do so on a > Windows build machine and the generated project (I presume there would > be only one) would only support 32-bit build targets. Couple that with > the fact that providing generated project files firmly places the > responsibility for those files with the zeromq community and I can see > why the cmake guys recommend just bundling cmake with your project. > > If we went down that road we would need to make sure that we bundle a > version of cmake that does not suffer from the relative path bug. I > think Martin was correct the other day when he suggested that the > typical use case at most Windows shops will be for the guy who > downloaded 0MQ to build the library on his workstation and then import > the source into the relevant corporate repository. If the project files > that he generated contained absolute paths, the next person to try to > build 0MQ will likely get a bunch of errors, which creates a very poor > first impression. > > Stuart > > > On 22/11/2011 08:25, Martin Sustrik wrote: > > Hi Stuart, > > > >> Andreas mentioned that cmake-generated VC projects retain some > >> dependency on cmake. I'll look into that using the build script that > >> Steve-o provided last month. In the meantime, I shall maintain this > >> patch on a separate branch. > > > > Great! Keep the list posted about the progress, problems etc. > > > > Martin > > > > > ------------------------------ > > Message: 9 > Date: Wed, 23 Nov 2011 10:30:24 +0200 > From: [email protected] > Subject: [zeromq-dev] 0MQ on embedded devices - Quadrocopter project > To: [email protected] > Message-ID: > <[email protected]> > Content-Type: text/plain;charset=iso-8859-1 > > Hi all, > > I'm new to 0MQ but have been devouring the documentation for the past two > days. I can easily relate to it in my day job (and will use it in an > Enterprise setting), but I have something more interesting in mind for it > right now. > > It seems to be the perfect missing link in the embedded world to bring > devices and cloud services together - but that means it needs a port to > microprocessor platforms like PIC, AVR and ARM. I'm talking about running > 0MQ on a device with no operating system and an embedded TCP/IP stack (or > no TCP/IP at all). > > Has this kind of thing been tried? The source seems portable enough to > attempt this. > > As a proof of concept I'd like to port it to a LPC2387 processor running > .Net Micro Framework. The core 0MQ lib would be native C, layered with > NETMF in C# over the API. This will basically give the ability to run > native C real-time routines and elegantly interact with the C# "business > logic" layer above it using messages instead of threads or callbacks. > > Initially I don't need TCP and will only use Inproc. It would be > interesting to see if it would be possible to implement a Serial transport > for device to device comms too. > > The architecture has me all excited because it solves a great many > problems in the embedded world and I think 0MQ should be a foundational > component in the "The Internet Of Things" movement. > > I'd like to build a real device in the form of a Quadrocopter. See > http://www.tinyclr.com/forum/2/4454/ . It is early days, but if you look > at the architecture I am proposing there, you'll immediately see why 0MQ > is the right choice... It just needs to run on a tiny little chip, in a > deterministic way, and a crash in the software would mean a crash in the > hardware (by falling out of the sky :) ) > > Am I crazy and wasting my time? If there are others equally nuts, are you > interested in helping me with this journey? > > Rudie > > > > ------------------------------ > > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > > > End of zeromq-dev Digest, Vol 47, Issue 73 > ****************************************** >
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
