Re: [zeromq-dev] Time-reordering queue

2022-11-10 Thread Jeff Shanab
This topic reminds me of how rtsp/rtp streams operate.
In that case it is inefficient to try and reorder on the send side so the
client(s) reorder and toss if not recoverable within a window.
each packet has a monotonically increasing seq number. The reorder buffer
is in the client.

This is especially important in the multicast case where single sender
multiple subscribers, You cannot have one bad subscriber bring down
everyone else.

On Thu, Nov 10, 2022 at 6:11 PM Francesco 
wrote:

> Hi Brett,
> thanks, this is really very helpful!
> I went through the README and the code... just one question:
>
> As the very first paragraph indicates, "The streams need not be
> synchronized in (real) time but must be strictly ordered in each
> stream"... I guess that, translating in ZMQ context, it means that the
> data structure is born to sort (by time) packets received over a set of k
> different SUB (or similar) sockets having each 1 endpoint; in such context
> each ZMQ SUB socket would be 1 stream for the zipper. This is the only way
> to satisfy the ordering criteria inside each stream, right?
> I'm asking because in my case the application is using just 1 single SUB
> that is connected with zmq_connect() to a number N of TCP endpoints. That
> makes the order of packets obtained from  zmq_msg_recv()  not
> time-ordered...
>
> Thanks!!
>
> Francesco
>
>
> Il giorno gio 10 nov 2022 alle ore 11:12 Brett Viren <
> brett.vi...@gmail.com> ha scritto:
>
>> Hi Francesco,
>>
>> I implemented such an algorithm in C++ which I call "zipper".
>>
>> The idea is simply to maintain a min-heap priority queue keyed on the
>> timestamp and surround that with policy logic to decide when to push
>> and pop based on examining the system clock.  I've implemented two
>> policies.  Either a maximum latency bound is asserted at the cost of
>> possible message loss or the merge is lossless at the risk of unbound
>> latency.
>>
>> It is a rather simple pattern and this description alone may be enough
>> to implement it yourself but you may also take a look at this repo
>> with code, performance results and other docs.
>>
>> https://github.com/brettviren/zipper
>>
>> Though I failed to make it explicit, this code may be considered
>> licensed under the LGPL.  Let me know if you wish to use the code and
>> I'll add proper license info.
>>
>> The zipper.hpp implementation is in terms of C++ data objects and
>> independent from zeromq per se (only needs C++ standard library).
>> But, it was written with the assumption that it would be sandwiched
>> between ZeroMQ input and output sockets.  Providing a layer to marshal
>> data in to / out from the zipper is then the duty of the application.
>>
>> Note, my repo was for development purposes.  The zipper.hpp file was
>> then copied into a production repository and that copy may have some
>> bug fixes which I have not ported back to the stand-alone development
>> version.  The production version is here:
>>
>> https://github.com/DUNE-DAQ/trigger/blob/develop/plugins/zipper.hpp
>>
>> -Brett.
>>
>> On Wed, Nov 9, 2022 at 5:20 PM Francesco 
>> wrote:
>> >
>> > Hi all,
>> >
>> > I have written two applications using ZMQ PUB-SUB pattern (over TCP
>> transport).
>> > The subscriber application has its SUB socket connected to multiple
>> PUBs (multiple tcp endpoints). Each message sent by the PUB encodes the
>> timestamp (as obtained from clock_gettime() syscall at TX side using
>> monotonically increasing clock) of the event described by the ZMQ message.
>> >
>> > The subscriber needs to process the data stream _strictly_ in order.
>> However the multiple publishers have no coordination and they will emit
>> messages at different rates, each with its own timestamp. The only
>> guarantee that I have, according to ZMQ docs, is that the SUB socket will
>> perform "fair dequeueing", but that's not enough to guarantee that every
>> zmq_msg_t received from the SUB socket will have a monotonically increasing
>> timestamp: it depends on the filling level of the TCP rx/tx kernel buffers,
>> the zmq HWMs, etc.
>> >
>> > For this reason I'm looking for some algorithm that
>> > * allows me to push zmq_msg_t pulled out of the SUB socket (without
>> strict time ordering)
>> > * allows me to pull out zmq_msg_t that have a timestamp monotonically
>> increasing
>> > * introduces a fixed max latency of N msecs (configurable)
>> >
>> > Do you have any pointer for such kind of problem?
>> > Anybody already hit a similar issue?
>> >
>> > Thanks for any help,
>> >
>> > Francesco Montorsi
>> >
>> > ___
>> > zeromq-dev mailing list
>> > zeromq-dev@lists.zeromq.org
>> > https://lists.zeromq.org/mailman/listinfo/zeromq-dev
>> ___
>> zeromq-dev mailing list
>> zeromq-dev@lists.zeromq.org
>> https://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>
> ___
> zeromq-dev mailing list
> 

Re: [zeromq-dev] TLS (openssl) for ZeroMQ

2018-12-26 Thread Jeff Shanab
In a lot of cases (mbtls) just don't link statically and the license issue
is moot. But linking dynamically is preferred for more issues than license.

I think there are a few things here to consider, and forgive me if I get
the jargon wrong. There are other people here that are the experts.

If you can use the OS implementation you can use their store, be ensured
that the most recent security updates have been applied and a well
optimized solution. (ok some of that may be up for debate, they have
security updates becasue they are most attacked.)

In some countries, even on windows, you just cannot legally use OpenSSL. So
ability to swap it out is really good.
Some devices do not play nice and you really need to talk to them with an
implementation they can work with (ie axis cameras vs ACTi cameras)

If we write code into ZMQ that depends on a particular TLS implementation,
we have done it wrong!



On Wed, Dec 26, 2018 at 10:11 AM Luca Boccassi 
wrote:

> There's also NSS from Mozilla which is under MPL and thus compatible,
> and does not introduce any restriction on third party code.
>
> There are then other less-known alternatives like wolfssl, mbed ssl or
> matrixssl which are all gpl2+ so cannot be used by proprietary products
> or static builds. But they all have commercial licenses available, so
> it can be used by your company for their product if they buy the
> license.
>
> On Tue, 2018-12-25 at 23:35 +0100, Luca Boccassi wrote:
> > Note that as an alternative to openssl there's gnutls which is lgpl2+
> > and
> > thus is compatible - but only for dynamic linking, proprietary
> > applications
> > statically linking to libzmq thanks to it's exception will not be
> > able to
> > statically link to gnutls.
> >
> > On Tue, 25 Dec 2018, 21:13 Luca Boccassi  > wrote:
> >
> > > On Tue, 2018-12-25 at 21:05 +0100, 林宝龙 wrote:
> > > > I suggested to use curve directly, but as a hole system, they
> > > > didn't
> > > > want
> > > > to have two key management system, TLS was there which was used
> > > > by
> > > > other
> > > > node. And another reason they gave to me is the curve was not
> > > > been
> > > > used so
> > > > much by big companies compare to TLS, even it's simple than TLS.
> > > > Further
> > > > more the running environment has already had OpenSSL installed,
> > > > use
> > > > openssl
> > > > can lower the security libraries maintenance.
> > >
> > > First of all curve was created by expert cryptographers, and it's
> > > extensively used, so it's not really a problem. The crypto
> > > primitives
> > > are provides by libsodium, which again is a very high quality
> > > library
> > > and used by many, many applications and libraries, and will most
> > > likely
> > > be already installed everywhere.
> > >
> > > Regarding key management, are you aware that there's the ZAP
> > > protocol?
> > > You can use it to implement the key management scheme you prefer,
> > > programmatically. For example, you could map 1:1 from SSL keys to
> > > curve
> > > keys internally.
> > >
> > > > About the license problem, as you explained to me, it is a big
> > > > problem, I
> > > > saw there is an issue which was registered 2 years ago to change
> > > > the
> > > > libzmq's license, but it is not coming to end. I'll check with my
> > > > colleagues how to make the license issue gone?  Come back to you
> > > > when
> > > > I
> > > > have more information.
> > >
> > > Again - you *cannot* make the license issue go away. We have been
> > > trying to relicense to MPL2 for years, it will take years to
> > > finish, if
> > > ever. This is not something that can be worked around or "hacked".
> > > It's
> > > a legal issue.
> > >
> > > > Best regards,
> > > > Baolong
> > > >
> > > > On Tue, 25 Dec 2018, 12:31 Luca Boccassi  > > > wrote:
> > > >
> > > > > On Tue, 2018-12-25 at 00:53 +0100, 林宝龙 wrote:
> > > > > > The problem of first option we met is that OpenSSL provides a
> > > > > > lot
> > > > > > configurable things, for example, trust group, external
> > > > > > verification
> > > > > > callback, etc. We must add more options to sockopt to have
> > > > > > such
> > > > > > things
> > > > > > configurable. For the callback functions, if we continue
> > > > > > using
> > > > > > setsockopt,
> > > > > > we need to cast function pointer to void pointer and vice
> > > > > > versa,
> > > > > > looks not
> > > > > > good.
> > > > >
> > > > > As mentioned, there is really no alternative to continue
> > > > > supporting
> > > > > bindings. Also, exposing a third party API/ABI again would mean
> > > > > that
> > > > > the users would need to start worrying about OpenSSL's API/ABI
> > > > > changes,
> > > > > and keep them in sync with the internal usage of the library.
> > > > > That
> > > > > would not be maintainable.
> > > > >
> > > > > So it looks like there are both legal and implementation
> > > > > problems.
> > > > > So
> > > > > let's take a step back: why is the current
> > > > > encryption/authentication
> > > > > 

Re: [zeromq-dev] TLS (openssl) for ZeroMQ

2018-12-24 Thread Jeff Shanab
Do not tie yourself to OpenSSL. There are export restrictions! Please take
a look at how culr abstracts the TLS implementationa nd allows us to swap
in mbedtls for example.

On Mon, Dec 24, 2018 at 6:53 PM 林宝龙  wrote:

> The problem of first option we met is that OpenSSL provides a lot
> configurable things, for example, trust group, external verification
> callback, etc. We must add more options to sockopt to have such things
> configurable. For the callback functions, if we continue using setsockopt,
> we need to cast function pointer to void pointer and vice versa, looks not
> good.
>
> About the licence issue, I'm not familiar with those licenses, and I have
> asked someone inside my company, got the answer that I can use OpenSSL in
> libzmq with an exception, I don't know how. He said that we will share the
> code out in the end, but can't contribute back to libzmq directly. Does it
> same as what you concern? Do you have more information that we must stop
> using OpenSSL inside libzmq?
>
>
> On Mon, 24 Dec 2018, 23:42 Luca Boccassi 
>> On Mon, 24 Dec 2018, 23:03 林宝龙 >
>>> Hi,
>>>
>>> We are adding TLS support for ZeroMQ(based on 4.2.5). Product reason, we
>>> choosed OpenSSL as TLS library.
>>>
>>> Ask community for suggestions, which solution below is better?
>>> 1. Use TLS public certification, private key, etc as socket option (set
>>> through setsockopt), ZeroMQ manages the OpenSSL context, one  OpenSSL
>>> context per socket_base_t object.
>>> 2. Use OpenSSL context as socket option(set through setsockopt),
>>> external application should provide the OpenSSL context, with public
>>> certification, private key, etc. set in context level, all ssl connections
>>> share the same configuration as the input OpenSSL context.
>>>
>>> At beginning we choosed the first solution, like curve, use public
>>> certification, private key as the socket option. But later on, we found the
>>> second solution that use external OpenSSL context can make the ZeroMQ code
>>> simpler, and more flexible, external application can configure the OpenSSL
>>> context without change the ZeroMQ socket options.
>>>
>>> Welcome your comments.
>>>
>>> Best regards,
>>> Baolong
>>>
>>
>> The first option would be better, exposing third party API and ABI would
>> be a nightmare, especially for bindings. O
>>
>> But the most important issue is that the Openssl license is not
>> compatible with libzmq, which is licensed under the lgpl3, so I'm afraid
>> such combination will not be legally distributable. At least not without a
>> relicensing effort to add an exception - we are already trying that to
>> change to mpl2 and are nowhere near done unfortunately.
>>
>>> ___
>> zeromq-dev mailing list
>> zeromq-dev@lists.zeromq.org
>> https://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> https://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev


[zeromq-dev] I changed a few files to get things working locally with cmake and to insure -mt is correct

2018-06-24 Thread Jeff Shanab
 CMakeLists.txt

index 99e75c3d..d3722b1d 100644
@@ -35,6 +35,29 @@ if(COMPILER_SUPPORTS_C11)
 set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -std=gnu11")
 endif()

+SET(RUNTIME_TYPE)
+if(MSVC)
+option(wxBUILD_USE_STATIC_RUNTIME "Link using the static runtime
library" OFF)
+
+set(MSVC_RUNTIME_TYPE "-md")
+if(DEFINED wxBUILD_USE_STATIC_RUNTIME AND wxBUILD_USE_STATIC_RUNTIME)
+set(MSVC_RUNTIME_TYPE "-mt")
+# Set MSVC runtime flags for all configurations
+foreach(cfg "" ${CMAKE_CONFIGURATION_TYPES})
+set(flag_var CMAKE_CXX_FLAGS)
+if(cfg)
+string(TOUPPER ${cfg} cfg_upper)
+set(flag_var "${flag_var}_${cfg_upper}")
+endif()
+if(${flag_var} MATCHES "/MD")
+string(REGEX REPLACE "/MD" "/MT" ${flag_var}
"${${flag_var}}")
+endif()
+endforeach()
+endif()
+SET(RUNTIME_TYPE ${MSVC_RUNTIME_TYPE})
+endif()
+
+
 if(NOT MSVC)
 # clang 6 has a warning that does not make sense on multi-platform code
 CHECK_CXX_COMPILER_FLAG("-Wno-tautological-constant-compare"
CXX_HAS_TAUT_WARNING)
@@ -489,8 +512,8 @@ if (MSVC)
 set (OPENPGM_INCLUDE_DIRS ${OPENPGM_ROOT}/include)
 set (OPENPGM_LIBRARY_DIRS ${OPENPGM_ROOT}/lib)
 set (OPENPGM_LIBRARIES
-  optimized
libpgm${MSVC_TOOLSET}-mt-${OPENPGM_VERSION_MAJOR}_${OPENPGM_VERSION_MINOR}_${OPENPGM_VERSION_MICRO}.lib
-  debug
libpgm${MSVC_TOOLSET}-mt-gd-${OPENPGM_VERSION_MAJOR}_${OPENPGM_VERSION_MINOR}_${OPENPGM_VERSION_MICRO}.lib)
+  optimized
libpgm${MSVC_TOOLSET}${RUNTIME_TYPE}-${OPENPGM_VERSION_MAJOR}_${OPENPGM_VERSION_MINOR}_${OPENPGM_VERSION_MICRO}.lib
+  debug
libpgm${MSVC_TOOLSET}${RUNTIME_TYPE}-gd-${OPENPGM_VERSION_MAJOR}_${OPENPGM_VERSION_MINOR}_${OPENPGM_VERSION_MICRO}.lib)
   endif ()
 else ()
   if (WITH_OPENPGM)
@@ -983,7 +1006,7 @@ if (MSVC)
   # of file content.
   set( CMAKE_STATIC_LINKER_FLAGS /ignore:4221 )
   set (PDB_OUTPUT_DIRECTORY "${CMAKE_CURRENT_BINARY_DIR}/bin")
-  set (PDB_NAME
"libzmq${MSVC_TOOLSET}-mt-gd-${ZMQ_VERSION_MAJOR}_${ZMQ_VERSION_MINOR}_${ZMQ_VERSION_PATCH}")
+  set (PDB_NAME
"libzmq${MSVC_TOOLSET}${RUNTIME_TYPE}-gd-${ZMQ_VERSION_MAJOR}_${ZMQ_VERSION_MINOR}_${ZMQ_VERSION_PATCH}")
   function(enable_vs_guideline_checker target)
 set_target_properties(${target} PROPERTIES
 VS_GLOBAL_EnableCppCoreCheck true
@@ -997,10 +1020,10 @@ if (MSVC)
 endif()
 set_target_properties (libzmq PROPERTIES
   PUBLIC_HEADER "${public_headers}"
-  RELEASE_POSTFIX
"${MSVC_TOOLSET}-mt-${ZMQ_VERSION_MAJOR}_${ZMQ_VERSION_MINOR}_${ZMQ_VERSION_PATCH}"
-  RELWITHDEBINFO_POSTFIX
"${MSVC_TOOLSET}-mt-${ZMQ_VERSION_MAJOR}_${ZMQ_VERSION_MINOR}_${ZMQ_VERSION_PATCH}"
-  MINSIZEREL_POSTFIX
"${MSVC_TOOLSET}-mt-${ZMQ_VERSION_MAJOR}_${ZMQ_VERSION_MINOR}_${ZMQ_VERSION_PATCH}"
-  DEBUG_POSTFIX
"${MSVC_TOOLSET}-mt-gd-${ZMQ_VERSION_MAJOR}_${ZMQ_VERSION_MINOR}_${ZMQ_VERSION_PATCH}"
+  RELEASE_POSTFIX
"${MSVC_TOOLSET}${RUNTIME_TYPE}-${ZMQ_VERSION_MAJOR}_${ZMQ_VERSION_MINOR}_${ZMQ_VERSION_PATCH}"
+  RELWITHDEBINFO_POSTFIX
"${MSVC_TOOLSET}${RUNTIME_TYPE}-${ZMQ_VERSION_MAJOR}_${ZMQ_VERSION_MINOR}_${ZMQ_VERSION_PATCH}"
+  MINSIZEREL_POSTFIX
"${MSVC_TOOLSET}${RUNTIME_TYPE}-${ZMQ_VERSION_MAJOR}_${ZMQ_VERSION_MINOR}_${ZMQ_VERSION_PATCH}"
+  DEBUG_POSTFIX
"${MSVC_TOOLSET}${RUNTIME_TYPE}-gd-${ZMQ_VERSION_MAJOR}_${ZMQ_VERSION_MINOR}_${ZMQ_VERSION_PATCH}"
   RUNTIME_OUTPUT_DIRECTORY "${CMAKE_CURRENT_BINARY_DIR}/bin"
   COMPILE_DEFINITIONS "DLL_EXPORT"
   OUTPUT_NAME "libzmq")
@@ -1010,10 +1033,10 @@ if (MSVC)
 add_library (libzmq-static STATIC ${sources}
${CMAKE_CURRENT_BINARY_DIR}/version.rc)
 set_target_properties (libzmq-static PROPERTIES
   PUBLIC_HEADER "${public_headers}"
-  RELEASE_POSTFIX
"${MSVC_TOOLSET}-mt-s-${ZMQ_VERSION_MAJOR}_${ZMQ_VERSION_MINOR}_${ZMQ_VERSION_PATCH}"
-  RELWITHDEBINFO_POSTFIX
"${MSVC_TOOLSET}-mt-s-${ZMQ_VERSION_MAJOR}_${ZMQ_VERSION_MINOR}_${ZMQ_VERSION_PATCH}"
-  MINSIZEREL_POSTFIX
"${MSVC_TOOLSET}-mt-s-${ZMQ_VERSION_MAJOR}_${ZMQ_VERSION_MINOR}_${ZMQ_VERSION_PATCH}"
-  DEBUG_POSTFIX
"${MSVC_TOOLSET}-mt-sgd-${ZMQ_VERSION_MAJOR}_${ZMQ_VERSION_MINOR}_${ZMQ_VERSION_PATCH}"
+  RELEASE_POSTFIX
"${MSVC_TOOLSET}${RUNTIME_TYPE}-s-${ZMQ_VERSION_MAJOR}_${ZMQ_VERSION_MINOR}_${ZMQ_VERSION_PATCH}"
+  RELWITHDEBINFO_POSTFIX
"${MSVC_TOOLSET}${RUNTIME_TYPE}-s-${ZMQ_VERSION_MAJOR}_${ZMQ_VERSION_MINOR}_${ZMQ_VERSION_PATCH}"
+  MINSIZEREL_POSTFIX
"${MSVC_TOOLSET}${RUNTIME_TYPE}-s-${ZMQ_VERSION_MAJOR}_${ZMQ_VERSION_MINOR}_${ZMQ_VERSION_PATCH}"
+  DEBUG_POSTFIX
"${MSVC_TOOLSET}${RUNTIME_TYPE}-sgd-${ZMQ_VERSION_MAJOR}_${ZMQ_VERSION_MINOR}_${ZMQ_VERSION_PATCH}"
   COMPILE_FLAGS "/DZMQ_STATIC"
   OUTPUT_NAME "libzmq")
   endif()

-- builds/cmake/ZeroMQConfig.cmake.in
--
index 21222ef1..6b916b36 

[zeromq-dev] OMG. broken ZeroMQConfig.cmake

2018-06-24 Thread Jeff Shanab
On windows you link to .lib not .dll

The current Config returns the ZeroMQ_LIBRARY  (ALSO Wrong, suppose to be
ZeroMQ_LIBRARIES)

 ZeroMQ_LIBRARY = C:/Program Files/ZeroMQ/bin/libzmq-v140-mt-gd-4_3_1.dll
 ZeroMQ_LIBRARY = C:/Program Files/ZeroMQ/lib/libzmq-v140-mt-sgd-4_3_1.lib

note the static one is correct for linking,
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev


[zeromq-dev] Site and build issues

2018-06-23 Thread Jeff Shanab
On WIndows, this has gotten a bit ugly.

The get sources for 4.2.3 dowloads a zip that when expanded either has a
CMAKE that fails or a  sln that creates libs and dlls all with the same
name. yuk

The windows installer goes to 4.0.4

Pulling from git has a useable Cmake and the sln has the preferred
structure with boost style library notations but they are a bit off..

ie libzmq-v140-mt-gd-4_3_1

But it is built /md  (Which is preferred in my mind as it is the default
when people create a project)
It is suppose to be vc140 not v140

The git links that are under Suse are not git repos and are missleading the
real link is rather hidden in the middle of the Development Master
paragraph.

I would expect to see multiple links, Master, stable at top of page or
clearly set under a Sources heading. I wasted a bit of time with that one.

Looks like you are creating in the install a config file but there is no
version in the path. I gotta remember to set a versioned path BEFORE I
generate the project next time.
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
https://lists.zeromq.org/mailman/listinfo/zeromq-dev


Re: [zeromq-dev] Memory management

2016-04-14 Thread Jeff Shanab
Thanks I think I have some Ideas to try,

On Thu, Apr 14, 2016 at 7:08 AM, Auer, Jens <jens.a...@cgi.com> wrote:

> Hi,
>
> there is zmq_msg_init_data which gets a callback which is called when the
> message is released. However, it is not fully zero-copy because some
> copying is done when receiving messages. With 4.2, this is reduced, but
> until that, the data is received into a fixed buffer and then copied into
> the message.
>
> That all reminds me that I wanted to add the possibility to use custom
> allocator functions to be able to use a memory pool. I think it should be
> possible, e.g. by setting function pointers as zmq context options, plus
> void* hint that can be set too.
>
> Cheers,
>   Jens
>
> --
> *Jens Auer *| CGI | Software-Engineer
> CGI (Germany) GmbH & Co. KG
> Rheinstraße 95 | 64295 Darmstadt | Germany
> T: +49 6151 36860 154
> *jens.a...@cgi.com* <jens.a...@cgi.com>
> Unsere Pflichtangaben gemäß § 35a GmbHG / §§ 161, 125a HGB finden Sie unter
> *de.cgi.com/pflichtangaben* <http://de.cgi.com/pflichtangaben>.
>
> CONFIDENTIALITY NOTICE: Proprietary/Confidential information belonging to
> CGI Group Inc. and its affiliates may be contained in this message. If you
> are not a recipient indicated or intended in this message (or responsible
> for delivery of this message to such person), or you think for any reason
> that this message may have been addressed to you in error, you may not use
> or copy or deliver this message to anyone else. In such case, you should
> destroy this message and are asked to notify the sender by reply e-mail.
> ------
> *Von:* zeromq-dev-boun...@lists.zeromq.org [
> zeromq-dev-boun...@lists.zeromq.org]" im Auftrag von "Jeff Shanab [
> jsha...@jfs-tech.com]
> *Gesendet:* Donnerstag, 14. April 2016 12:06
> *An:* ZeroMQ development list
> *Betreff:* [zeromq-dev] Memory management
>
> I am writing an app in C++ and using libzmq directly, not much of the c++
> wrapper stuff.
>
> I am interested in zero copy or at least minimizing the number of copies
> of large buffers.
>
> But am running across an all too common issue, Each library used wants to
> have their own memory management forcing me to copy between the systems.
>
> Is there a way I could use boost shared_ptr with the functions
> so ZMQ could dereference/delete after the send?
>
> In fact is there a way to hook into the system and get a callback when it
> goes to delete with the client pointer so I can delete or return it to a
> pool?
>
>
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev


[zeromq-dev] Memory management

2016-04-14 Thread Jeff Shanab
I am writing an app in C++ and using libzmq directly, not much of the c++
wrapper stuff.

I am interested in zero copy or at least minimizing the number of copies of
large buffers.

But am running across an all too common issue, Each library used wants to
have their own memory management forcing me to copy between the systems.

Is there a way I could use boost shared_ptr with the functions
so ZMQ could dereference/delete after the send?

In fact is there a way to hook into the system and get a callback when it
goes to delete with the client pointer so I can delete or return it to a
pool?
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev


Re: [zeromq-dev] Moving list to Google groups?

2016-04-14 Thread Jeff Shanab
I am also a mostly silent lurker and will probably not follow a google
group. :-(

On Thu, Apr 14, 2016 at 3:05 AM, Dinu Gherman 
wrote:

> Hi!
>
> I'm a silent lurker here, but I would most likely stop following this list
> after a move to google groups. I don't like imposing the use of an account
> already connecting to lots of data where any email address anywhere would
> be just what is needed. Sure, you can user other identities, but that's a
> pain.
>
> Unrelated to ideology, I've tried using google groups for other groups
> imposing it on their members and I did not like the "user experience" at
> all, and after a while I gave up. I don't understand how people can like
> it. If it would be more like google mail, I
> might like it.
>
> I would give Mailman 3 a try which should now have an interface decades
> better than Mailman 2, which is probably literally true if you skip the
> plural s.
>
> Cheers,
>
> Dinu
>
> --
> Sent on the move.
> Von unterwegs gesendet.
>
> > Am 14.04.2016 um 00:45 schrieb Pieter Hintjens :
> >
> > Hi all,
> >
> > I'd like to raise this question for discussion. The problem is that
> > zeromq-dev is running on an iMatix server, and I'd like to remove
> > iMatix infrastructure from our community, over time. It's a matter of
> > long term sustainability.
> >
> > (Apart from the list, iMatix also hosts downloads.zeromq.org which we
> > can start to move to Github release attachments IMO.)
> >
> > Anyhow, re. lists, let's weigh pros and cons of Google groups versus
> > other options. I'll make the decision based on this thread and other
> > factors.
> >
> > Thanks
> > Pieter
> > ___
> > zeromq-dev mailing list
> > zeromq-dev@lists.zeromq.org
> > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev


Re: [zeromq-dev] Delay in receive by SUB from PUB

2016-03-12 Thread Jeff Shanab
I have seen this when I make a mistake and over-consume from the publisher
on multipart messages. the subscriber then blocks.
In my case the next message eventually comes along and things resume, but
out of sync.

To avoid this I created a small class that recvies the entire multipart
message then it either has or has not enough "frames."
I separated my interpretation of the frames from their recv.

On Fri, Mar 11, 2016 at 6:39 AM, Navneet Kumar 
wrote:

> Hello everone
>
> I am building a pubsub, wherein the PUB and the SUB socket are on the same
> host.
> I am able to send lots of messages through it. The latency of the system
> is around 2-50 ms.
>
> But out of blue some messages get stuck for 5-6 seconds before receiving.
> I have put the logs and added timestamps to the message itself.
> The publisher publishes and sets the time stamp, the subscriber timestamp
> has a
> difference of 5-10 seconds. This occurs for roughly 1 in 1000 messages.
>
> I am using aws c4.xlarge machine. I tried ss and there were few blips in
> the recv and send queue.
> If i am sending lots of messages in bulk then it sometimes get stuck and
> the resumes, with no
> messages being lost. Sometimes a single message itself without any other
> load gets stuck.
>
> Has anyone faced such a scenario or give any pointers to look.
>
>
>
> --
> Navneet Kumar
>
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev


Re: [zeromq-dev] libzmq\builds\msvc\msvc.sln is missing

2016-02-05 Thread Jeff Shanab
Cmake does not build!. And it certainly is a different paradigm but I have
grown to love it.

Like bakefiles it generates the projects from a single set of descriptive
CMakeList.txt files

The philosophy is:
   Out of source build.
 You change into a fresh directory and generate into it. This is NEVER
CHECKED IN and build products do not pollute your repo directory
 I go one step furthor and keep my cmake projects in a tree along side,
at a peer level the actual repo so even my CMakeList files don't pollute my
repo. And I can have multiple projects using the same source tree.
   Once these projects are generated, regeneration takes a very short time,
I consider this negligible when compared with changeing every dependency in
a large project or creating a new similar project. Ever manually edit a VS
sln file?  You only need to regen  when files are added,remove, or moved.
or you decide to change some compile and linker options.
In reality you can check in the makefiles and solutions but they have
all absolute paths! So unless you have a team wide convention, it goes
against the grain.

I like it becuase  I have a build root env variable on all my machines. I
check out my cmake project on any machine and run the python prep script I
created that generates into ${BUILD_ROOT}/{$Projectname}. I do this on
Apple, linux, windows 32/64 bit VS2010,VS2012, VS2013, Eclipse. And I will
be trying Ninja for the build server. If I want to change the version of
boost I change 1 line in the cmake, regenerate and open the sln, all
projects in the sln are updated. commit, pull down to apple, regen and open
xcode. done.





I like it because I generate

On Fri, Feb 5, 2016 at 6:59 AM, Pieter Hintjens  wrote:

> I've just tried CMake and it appears to work up to a point. That is:
>
> - you need to install it
> - you need to create a directory to build in
> - you need to run it (that takes some time, it goes through a whole
> load of "is this linux? no? wow" checks...
> - you then get a ZeroMQ.sln that you can pass to MSVC
>
> Whereas the master already contains a libzmq.sln that you can pass to MSVC.
>
> So while CMake surely works, I don't see the benefit of using it, you
> have a lot of extra steps to get the same results.
>
> Also it does not work for CZMQ and other libraries, and does not
> AFAICs work with libsodium.
>
> So I'd not recommend it.
>
> -Pieter
>
> On Fri, Feb 5, 2016 at 12:52 PM, Sergei Nikulov
>  wrote:
> > 2016-02-05 14:25 GMT+03:00 Pieter Hintjens :
> >> Here are the steps to build libzmq from master, using VS2015 in a
> >> cmd.exe window:
> >>
> >> git clone https://github.com/zeromq/libzmq
> >> cd libzmq\builds\msvc
> >> configure
> >> cd build
> >> buildall
> >>
> >> If you use an earlier MSVC, look at buildall.bat to see how to call
> >> build for older compilers.
> >
> > Hi Pieter,
> >
> > Is CMake not recommended and not supported?
> >
> >> -Pieter
> >>
> >>
> >> On Fri, Feb 5, 2016 at 9:37 AM, B. Scott Harper 
> wrote:
> >>> I had assumed that, since Visual Studio solutions were provided, CMake
> would
> >>> not be useful for configuring builds on Windows. I would be happy to
> learn
> >>> that my assumption was erroneous.
> >>>
> >>> On Fri, Feb 5, 2016 at 5:26 PM, Sergei Nikulov <
> sergey.niku...@gmail.com>
> >>> wrote:
> 
>  2016-02-05 11:08 GMT+03:00 Jihad Mahmoud :
>  > Hello All
>  >
>  > I am using ZMQ for the first time and while I was following the
>  > instructions
>  > for installing it on Windows libzmq\builds\msvc\msvc.sln wasn't
> found. I
>  > assumed the libmzq in VS2010 is the alternative sln nevertheless
> when I
>  > tried to load it in Visual C++ 2010, it couldn't be loaded as all
> .prop
>  > files weren't found. I open the VS2010 directory and couldn't find
> any
>  > of
>  > the required .prop file instead I have found only the project
> property
>  > file.
>  >
>  > In this case what should I do? I searched for few hours on the
> internet
>  > and
>  > couldn't find a solution.
> 
>  If you familiar with CMake https://cmake.org/, I advice you to use it
>  for project generation.
> 
>  >
>  > Thanks
>  > Jihad
>  >
>  > --
>  > Jihad Fahmi Mahmoud
>  > 大阪大学情報科学研究科情報システム工学博士1年 竹村研究室配属
>  > Ph.D. Candidate, Prof Takemura Laboratory,
>  > Information Systems Engineering Department,
>  > Graduate School of Information Sciences and Technology,
>  > Osaka University
>  >
>  > ___
>  > zeromq-dev mailing list
>  > zeromq-dev@lists.zeromq.org
>  > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>  >
> 
> 
> 
>  --
>  Best Regards,
>  Sergei Nikulov
>  ___
>  zeromq-dev mailing list
>  

[zeromq-dev] 64bit Issue discovered with zmq_getsockopt(..., ZMQ_RCVMORE, ...

2015-12-12 Thread Jeff Shanab
Using ZMQ 4.0.4 on windows 64bit in Visual studio with a simple REQ-REP
with multipart messages.

All examples and guide show code like

int64_t more;
size_t more_size = sizeof more;
do {
 /* Create an empty ØMQ message to hold the message part */
 zmq_msg_t part;
 int rc = zmq_msg_init ();
 assert (rc == 0);
 /* Block until a message is available to be received from socket */
 rc = zmq_msg_recv (, socket, 0);
 assert (rc != -1);
 /* Determine if more message parts are to follow */
 rc = zmq_getsockopt (socket, ZMQ_RCVMORE, , _size);
 assert (rc == 0);
 zmq_msg_close (); } while (more);


I found that the value of more is a ridiculously large negative integer
and fails to detect the last frame unless I initialize it to zero.

(note Debug in GCC zeros memory, Visual Studio does not.)

Inspection of the value in hex may reveal a 64 bit porting problem,

The values is 0x

Which is setting it to a int const without the ull specifier 

Anyway I change "int64_t more;" to "int64_t more = 0;" and operation
is restored.
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev


Re: [zeromq-dev] 64bit Issue discovered with zmq_getsockopt(..., ZMQ_RCVMORE, ...

2015-12-12 Thread Jeff Shanab
It took a bit of time to find out the guide led me down the wrong path.
:-(
If it doesn't work, it really shouldn't be the suggested code in the
guide.

On Sat, Dec 12, 2015 at 4:57 PM, KIU Shueng Chuan <nixch...@gmail.com>
wrote:

> The type of that socket option was changed to "int" since version 3.2.x
>
> Rather than extracting the more flag using getsockopt, you can also do:
>
> int more = zmq_msg_more ();
> On 13 Dec 2015 03:01, "Jeff Shanab" <jsha...@jfs-tech.com> wrote:
>
>> Using ZMQ 4.0.4 on windows 64bit in Visual studio with a simple REQ-REP
>> with multipart messages.
>>
>> All examples and guide show code like
>>
>> int64_t more;
>> size_t more_size = sizeof more;
>> do {
>>  /* Create an empty ØMQ message to hold the message part */
>>  zmq_msg_t part;
>>  int rc = zmq_msg_init ();
>>  assert (rc == 0);
>>  /* Block until a message is available to be received from socket */
>>  rc = zmq_msg_recv (, socket, 0);
>>  assert (rc != -1);
>>  /* Determine if more message parts are to follow */
>>  rc = zmq_getsockopt (socket, ZMQ_RCVMORE, , _size);
>>  assert (rc == 0);
>>  zmq_msg_close (); } while (more);
>>
>>
>> I found that the value of more is a ridiculously large negative integer
>> and fails to detect the last frame unless I initialize it to zero.
>>
>> (note Debug in GCC zeros memory, Visual Studio does not.)
>>
>> Inspection of the value in hex may reveal a 64 bit porting problem,
>>
>> The values is 0x
>>
>> Which is setting it to a int const without the ull specifier 
>>
>> Anyway I change "int64_t more;" to "int64_t more = 0;" and operation is 
>> restored.
>>
>>
>>
>>
>>
>>
>> ___
>> zeromq-dev mailing list
>> zeromq-dev@lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>
>>
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev


[zeromq-dev] zmq_msg_recv not blocking

2015-11-23 Thread Jeff Shanab
I have used a previous version of zmq with google protocol buffers a few
years ago but am trying a simpler project with the newest zmq and have run
into a problem.

Imagine the weather server and client converted to the multipart message
code in the guide. But when I call zmq_msg_recv(, subscriber,0), it
does not block!

do {
/* Create an empty ØMQ message to hold the message part */
zmq_msg_t part;
int rc = zmq_msg_init ();
assert (rc == 0);
/* Block until a message is available to be received from socket */
rc = zmq_msg_recv (, subscriber,0);

if (rc != 0)
{
std::cout << "First msg Recv error :" << zmq_errno() <<
zmq_strerror (zmq_errno()) << std::endl;
boost::this_thread::sleep(boost::posix_time::milliseconds(250));
continue;
};

rc = zmq_getsockopt (subscriber, ZMQ_RCVMORE, , _size);
assert (rc == 0);



With this code, I get

First msg Recv error :35Resource temporarily unavailable
First msg Recv error :60Operation timed out
First msg Recv error :60Operation timed out
First msg Recv error :60Operation timed out
First msg Recv error :60Operation timed out
First msg Recv error :60Operation timed out
First msg Recv error :60Operation timed out
First msg Recv error :60Operation timed out
First msg Recv error :60Operation timed out
First msg Recv error :60Operation timed out
First msg Recv error :60Operation timed out
First msg Recv error :60Operation timed out
First msg Recv error :60Operation timed out
First msg Recv error :60Operation timed out
First msg Recv error :60Operation timed out
First msg Recv error :60Operation timed o ...

This is on OSX. I am going to try windows and linux after work tonight.

Are there any known issues with 4.1.3, zmq_msg_recv and OSX ?
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev


Re: [zeromq-dev] zmq_msg_recv not blocking

2015-11-23 Thread Jeff Shanab
The Guide has an assert (rc == 0) that of course exited the program.
I replaced that with the if (rc != 0) block  to get the error

On Mon, Nov 23, 2015 at 8:31 AM, KIU Shueng Chuan <nixch...@gmail.com>
wrote:

> Note that zmq_msg_recv() returns >= 0 on success.
> On 23 Nov 2015 19:54, "Jeff Shanab" <jsha...@jfs-tech.com> wrote:
>
>> I have used a previous version of zmq with google protocol buffers a few
>> years ago but am trying a simpler project with the newest zmq and have run
>> into a problem.
>>
>> Imagine the weather server and client converted to the multipart message
>> code in the guide. But when I call zmq_msg_recv(, subscriber,0), it
>> does not block!
>>
>> do {
>> /* Create an empty ØMQ message to hold the message part */
>> zmq_msg_t part;
>> int rc = zmq_msg_init ();
>> assert (rc == 0);
>> /* Block until a message is available to be received from socket
>> */
>> rc = zmq_msg_recv (, subscriber,0);
>>
>> if (rc != 0)
>> {
>> std::cout << "First msg Recv error :" << zmq_errno() <<
>> zmq_strerror (zmq_errno()) << std::endl;
>>
>> boost::this_thread::sleep(boost::posix_time::milliseconds(250));
>> continue;
>> };
>>
>> rc = zmq_getsockopt (subscriber, ZMQ_RCVMORE, , _size);
>> assert (rc == 0);
>>
>> 
>>
>> With this code, I get
>>
>> First msg Recv error :35Resource temporarily unavailable
>> First msg Recv error :60Operation timed out
>> First msg Recv error :60Operation timed out
>> First msg Recv error :60Operation timed out
>> First msg Recv error :60Operation timed out
>> First msg Recv error :60Operation timed out
>> First msg Recv error :60Operation timed out
>> First msg Recv error :60Operation timed out
>> First msg Recv error :60Operation timed out
>> First msg Recv error :60Operation timed out
>> First msg Recv error :60Operation timed out
>> First msg Recv error :60Operation timed out
>> First msg Recv error :60Operation timed out
>> First msg Recv error :60Operation timed out
>> First msg Recv error :60Operation timed out
>> First msg Recv error :60Operation timed o ...
>>
>> This is on OSX. I am going to try windows and linux after work tonight.
>>
>> Are there any known issues with 4.1.3, zmq_msg_recv and OSX ?
>>
>> ___
>> zeromq-dev mailing list
>> zeromq-dev@lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>
>>
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev


Re: [zeromq-dev] zmq_msg_recv not blocking

2015-11-23 Thread Jeff Shanab
If I used zmq_send and zmq_recv it works.

If I use zmq_send on the server side and zmq_msg_recv on the client side,
it goes bonkers.

In this case the zmq_recv way is cleaner anyway. I will have to figure out
why the second combination didn't work when I have more time.

But in general, is it ok to mix the two?

On Mon, Nov 23, 2015 at 9:44 AM, Marcin Romaszewicz <mar...@brkt.com> wrote:

> That should be rc != -1. If you receive, say, 3 bytes, your error code
> will trigger. Those errno values could be from previous functions.
>
> On Mon, Nov 23, 2015 at 6:15 AM, Jeff Shanab <jsha...@jfs-tech.com> wrote:
>
>> The Guide has an assert (rc == 0) that of course exited the program.
>> I replaced that with the if (rc != 0) block  to get the error
>>
>> On Mon, Nov 23, 2015 at 8:31 AM, KIU Shueng Chuan <nixch...@gmail.com>
>> wrote:
>>
>>> Note that zmq_msg_recv() returns >= 0 on success.
>>> On 23 Nov 2015 19:54, "Jeff Shanab" <jsha...@jfs-tech.com> wrote:
>>>
>>>> I have used a previous version of zmq with google protocol buffers a
>>>> few years ago but am trying a simpler project with the newest zmq and have
>>>> run into a problem.
>>>>
>>>> Imagine the weather server and client converted to the multipart
>>>> message code in the guide. But when I call zmq_msg_recv(,
>>>> subscriber,0), it does not block!
>>>>
>>>> do {
>>>> /* Create an empty ØMQ message to hold the message part */
>>>> zmq_msg_t part;
>>>> int rc = zmq_msg_init ();
>>>> assert (rc == 0);
>>>> /* Block until a message is available to be received from
>>>> socket */
>>>> rc = zmq_msg_recv (, subscriber,0);
>>>>
>>>> if (rc != 0)
>>>> {
>>>> std::cout << "First msg Recv error :" << zmq_errno() <<
>>>> zmq_strerror (zmq_errno()) << std::endl;
>>>>
>>>> boost::this_thread::sleep(boost::posix_time::milliseconds(250));
>>>> continue;
>>>> };
>>>>
>>>> rc = zmq_getsockopt (subscriber, ZMQ_RCVMORE, ,
>>>> _size);
>>>> assert (rc == 0);
>>>>
>>>> 
>>>>
>>>> With this code, I get
>>>>
>>>> First msg Recv error :35Resource temporarily unavailable
>>>> First msg Recv error :60Operation timed out
>>>> First msg Recv error :60Operation timed out
>>>> First msg Recv error :60Operation timed out
>>>> First msg Recv error :60Operation timed out
>>>> First msg Recv error :60Operation timed out
>>>> First msg Recv error :60Operation timed out
>>>> First msg Recv error :60Operation timed out
>>>> First msg Recv error :60Operation timed out
>>>> First msg Recv error :60Operation timed out
>>>> First msg Recv error :60Operation timed out
>>>> First msg Recv error :60Operation timed out
>>>> First msg Recv error :60Operation timed out
>>>> First msg Recv error :60Operation timed out
>>>> First msg Recv error :60Operation timed out
>>>> First msg Recv error :60Operation timed o ...
>>>>
>>>> This is on OSX. I am going to try windows and linux after work tonight.
>>>>
>>>> Are there any known issues with 4.1.3, zmq_msg_recv and OSX ?
>>>>
>>>> ___
>>>> zeromq-dev mailing list
>>>> zeromq-dev@lists.zeromq.org
>>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>>>
>>>>
>>> ___
>>> zeromq-dev mailing list
>>> zeromq-dev@lists.zeromq.org
>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>>
>>>
>>
>> ___
>> zeromq-dev mailing list
>> zeromq-dev@lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>
>>
>
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev


Re: [zeromq-dev] zmq_msg_recv not blocking

2015-11-23 Thread Jeff Shanab
(Documentation needs update the assert rc == 0)
But it is suppose to block until it gets a message, a whole message event
the multiple parts.
If there is a serious error then I could see it exiting and catching the
next one on a retry but it NEVER blocks (Usually people have the opposite
problem)

On Mon, Nov 23, 2015 at 9:44 AM, Marcin Romaszewicz <mar...@brkt.com> wrote:

> That should be rc != -1. If you receive, say, 3 bytes, your error code
> will trigger. Those errno values could be from previous functions.
>
> On Mon, Nov 23, 2015 at 6:15 AM, Jeff Shanab <jsha...@jfs-tech.com> wrote:
>
>> The Guide has an assert (rc == 0) that of course exited the program.
>> I replaced that with the if (rc != 0) block  to get the error
>>
>> On Mon, Nov 23, 2015 at 8:31 AM, KIU Shueng Chuan <nixch...@gmail.com>
>> wrote:
>>
>>> Note that zmq_msg_recv() returns >= 0 on success.
>>> On 23 Nov 2015 19:54, "Jeff Shanab" <jsha...@jfs-tech.com> wrote:
>>>
>>>> I have used a previous version of zmq with google protocol buffers a
>>>> few years ago but am trying a simpler project with the newest zmq and have
>>>> run into a problem.
>>>>
>>>> Imagine the weather server and client converted to the multipart
>>>> message code in the guide. But when I call zmq_msg_recv(,
>>>> subscriber,0), it does not block!
>>>>
>>>> do {
>>>> /* Create an empty ØMQ message to hold the message part */
>>>> zmq_msg_t part;
>>>> int rc = zmq_msg_init ();
>>>> assert (rc == 0);
>>>> /* Block until a message is available to be received from
>>>> socket */
>>>> rc = zmq_msg_recv (, subscriber,0);
>>>>
>>>> if (rc != 0)
>>>> {
>>>> std::cout << "First msg Recv error :" << zmq_errno() <<
>>>> zmq_strerror (zmq_errno()) << std::endl;
>>>>
>>>> boost::this_thread::sleep(boost::posix_time::milliseconds(250));
>>>> continue;
>>>> };
>>>>
>>>> rc = zmq_getsockopt (subscriber, ZMQ_RCVMORE, ,
>>>> _size);
>>>> assert (rc == 0);
>>>>
>>>> 
>>>>
>>>> With this code, I get
>>>>
>>>> First msg Recv error :35Resource temporarily unavailable
>>>> First msg Recv error :60Operation timed out
>>>> First msg Recv error :60Operation timed out
>>>> First msg Recv error :60Operation timed out
>>>> First msg Recv error :60Operation timed out
>>>> First msg Recv error :60Operation timed out
>>>> First msg Recv error :60Operation timed out
>>>> First msg Recv error :60Operation timed out
>>>> First msg Recv error :60Operation timed out
>>>> First msg Recv error :60Operation timed out
>>>> First msg Recv error :60Operation timed out
>>>> First msg Recv error :60Operation timed out
>>>> First msg Recv error :60Operation timed out
>>>> First msg Recv error :60Operation timed out
>>>> First msg Recv error :60Operation timed out
>>>> First msg Recv error :60Operation timed o ...
>>>>
>>>> This is on OSX. I am going to try windows and linux after work tonight.
>>>>
>>>> Are there any known issues with 4.1.3, zmq_msg_recv and OSX ?
>>>>
>>>> ___
>>>> zeromq-dev mailing list
>>>> zeromq-dev@lists.zeromq.org
>>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>>>
>>>>
>>> ___
>>> zeromq-dev mailing list
>>> zeromq-dev@lists.zeromq.org
>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>>
>>>
>>
>> ___
>> zeromq-dev mailing list
>> zeromq-dev@lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>
>>
>
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev