> There was some discussion about allowing students to work on 0MQ via
> Google Summer of Code 2011. One of the things to be submitted with the
> application is a list of ideas for the work. Here are the few I came
> with. Please, do suggest more ideas...
>
Uh other suggestions then.
IPC for Win
Hi
> On 01/07/2011 02:36 PM, Daniel Cegiełka wrote:
>
> > I use only c/c++ on linux :)
>
> Say the endianness depends on the processor. Using C/C++ or Linux
> doesn't affect it in any way.
Very true. I find that especially for sending many small messages a
standardized message format is key. S
Sure but it won't be until the end of the week because I am not near my
development setup for a few days.
Regards,
Mikael
> Your patch does not apply to the master:
>
> sust...@istvan:~/zeromq2$ git apply
> 0001-Implement-maximum-message-size-and-a-socket-option-t.patch
> 0001-Implement-maximum
Hi
It has been a little while since I posted the first patch for this. This patch
applies ON TOP OF the previous patch and fixes the comments that I received on
the earlier patch (errors I had made really). It includes support for the
one_byte_size case and uses the logic that was agreed on for
Amongst other problems with it yeah. Do you think this is the right approach
and is this a feature 0mq needs?
Regards,
Mikael
> Mi Mikael,
>
> I've checked the patch. It looks OK, however, you've missed that the
> size is checked at two different places in decoder.cpp (one for
> messages
> with
Hi Samuel
Well it was not intended as a DOS defense at all, more along the lines of a way
to limit the size of messages that a receiver would be willing to accept in
case of memory limits and the like. I was thinking off adding something similar
to the sender to allow it to inform the API us
Hi
I picked up on a suggestion in another list about the idea of adding maximum
message sizes as a parameter to zmq and I whipped up a quick patch that is a
First attempt at implementing this.
My idea for an solution was to add a check to the decoder_t object and adding
another socket option
I noticed that later :)
I've compiled my zmq with my own FD_SETSIZE value so I guess that was why I
reacted.
> Note that the patch is applied to select.cpp, i.e. to internal 0MQ
> compilation unit. The FD_SETSIZE setting is invisible to client
> applications.
>
> Martin
Regards,
Mikael
_
> Additionally, I would suggest using a following simpler patch:
>
> index 78d3afd..663d5d7 100644
> --- a/src/select.cpp
> +++ b/src/select.cpp
> @@ -23,6 +23,7 @@
> #include
>
> #ifdef ZMQ_HAVE_WINDOWS
> +#define FD_SETSIZE 1024
> #include "winsock2.h"
> #elif defined ZMQ_HAVE_HPUX
>
Hi
Ah a lot of insightful replies. And yes I understand that 0mq is not about
security nor should it be, it is a scalability/messaging library with the
sanest API that I've encounter for a long time. I think that some combination
of an encrypted channel for secure key exchange along with
Hi
> 2) it can't tell ciphertext from plaintext. as previously mentioned,
> this ability requires changes to the wire-protocol. if security-related
> changes are to be introduced, i'd prefer to start at socket identity
> signing. (a la dnssec) you can imagine that this is a HUGE can of
> worms,
>
Hi
> Brian,
> > We are not security experts and would love feedback on this design.
> > It is quite simple, but for many of us, security is the show stopper
> > with 0MQ. This at least gets us moving in the right direction.
> >
> I am not a security expert either, but anyway: nice!
>
> One prob
Unfortunately yes I am on Win64 (heh just to be contrary), but I could write
some of the code for you if you wanna pick what needs done, but I couldn't
compile it unless it is general. However the method is quite simple. Just the
Boolean returning function. If you have more complex loops I sugge
<<0001-select-now-uses-Erase-Remove-idiom-for-retired-fds.patch>> Patch to use
Erase-Remove idiom in the select loop. It works in test and perf runs fine.
Regards,
Mikael
0001-select-now-uses-Erase-Remove-idiom-for-retired-fds.patch
Description: Binary data
__
Hi Pieter
I didn't get to posting my follow up Friday but it turns out that I had made
the second set of tests using a debug build rather than a release build which
was a significant disadvantage for the erase-remove idiom and even all the way
down to the 100 element array it was faster than th
Hi Pieter
I had a few moments so I tested a scale of values from 100 to 1 in vector
sizes. The Erase-remove idiom is indeed more expensive until the vectors grow
to be around 10k elements. From there the two diverge with the current way of
deleting getting more expensive than the erase-remo
Hi Pieter
I threw something here: git://gist.github.com/653390.git
> Mikael,
>
> Yes, I'm remotely interested... :-) If you can put the C++ test
> programs somewhere (e.g. gist.github.com) I'll try them on a Linux box
> and see what they give. It's worth seeing what the relative
> difference i
Hi
I ran a test of the concepts as I described them (had to correct an
issue that made microsofts STL go nuts over iterator invalidation as
usual when erasing). And the erase-remove idiom is an order of
magnitude faster. I am surprised at the great difference.
On an average of just 10 runs (not
Hi all
I was looking through the source code and I wondered if there is a specific
reason for something I observed. 0mq uses std::vector in several places often
typedef'ed or in through yarray.hpp. And that is just fine, but often when
values are removed they're removed one at a time during an
Hi
That's how I've dealt with it at my end. An old solution that simply works.
Besides the sense I got from 0mq's design and this list that it was that the
intent of the library that you should built these kind of solutions on top of
it. A heartbeat protocol (that I tweak depending on the pe
Hi there
Just as Kelly Brock and others I've already sold this. I switched because 0mq
resolved a lot of uncertainty in writing a high-performance dedicated
networking solution for an async RPC we're planning to use for a larger product
and I saw I could build a lot on top of 0mq. The main argu
Hi
> This is the same question I keep asking myself. I have a lot of
> experience with realtime apps on 'industrial PCs', but I've only
> recently started working with truly embedded systems. My
> colleagues---who have decades of experience in this space---feel that
> starting a C++ app from a col
Hi Steven
Hmm, I have no problem running code even without _NATIVE_WCHAR_T_DEFINED that
uses the wchar_t type. I believe that there is a define like this in most
relevant CRT files on windows (this was taken from a Windows SDK):
#ifndef _WCHAR_T_DEFINED
typedef unsigned short wchar_t;
#
That matches my experience with zeromq on another matter as well so I believe
that to be true
Regards,
Mikael
On 4 October 2010 15:04, Steven McCoy mailto:steven.mc...@miru.hk> > wrote:
http://msdn.microsoft.com/en-us/library/ms684497(VS.85).aspx
Wouldn't lack
Hi Steven
Well it is good news about the CRT stuff.
About the MIB_IFROW::wszName field isn't it just a question of how the WCHAR
define ends up. If you expect a MBCS value and a string is UNICODE a conversion
function (mbstowcs_s) is available AFAIK even with the /Zc:wchar_t- value set
Hi
> Seems to me that neither a VPN nor per-message security is desirable
> because the first makes walk-up-and-use impossible, and the second
> affects applications.
>
> Forgetting multicast for a minute, could we not do TLS for TCP
> connections by using devices, i.e. creating a VPN within the
Hi
I've worked a bit with some of these techniques and asked around to several
people I know locally and they all believe in using Shared Memory for larger
messages and named pipes for smaller ones. One guy recommended a solution of
having a shared memory block for the messages, creating an
Hi
>
> 1. From what I understand, the dependency on the DDK is only for
> development time (includes, import libs, etc.), not for runtime.
>
> 2. I would LOVE if the "ipc://" "protocol" was supported under Windows
> with a cheap-as-possible inter-process communication protocol (named
> pipes, LP
ikael Helbo Kjær
I've gotten a build of 2.0.9, but I haven't tested it unlike the 32-bit
build, but they are the same except for some settings in Visual Studio. Oh and
I had to give up on getting OpenPGM to work as its windows support is very bad
and its 64-bit support is
Hi,
I've gotten a build of 2.0.9, but I haven't tested it unlike the 32-bit build,
but they are the same except for some settings in Visual Studio. Oh and I had
to give up on getting OpenPGM to work as its windows support is very bad and
its 64-bit support is even worse. It depends on GCC exten
Hi
According to the docs IPC is not implemented on Windows.
Regards,
Mikael
>
> It's not working on Windows.
>
> I just do "ipc://whateverIlike"... in "bind" and "connect", right?
> Or do I need to do something else first?
___
zeromq-dev mailing list
Hi Martin
If naming clashes are a worry what about:
s.connect ("inproc://zeromq/log");
"system" seems a bit obvious for people to try and use especially if they
didn't truly read any documentation.
But the general idea of having sockets to communicate with zeromq is quite
excellent in genera
Hi Martin
> Well, the endpoint pointer should point to the socket itself. As can be
> seen from the stack, the socket is currently executing 'send' function.
>
> The two possibilities I see is:
>
> 1. The socket was already closed, then send was called on it.
> 2. The socket is being used from
Hi everyone
I've been tinkering with my system and I've hit a problem inside zmq that I
haven't been able to debug or figure out just yet. My code is trying to send
when I hit it.
I get an access violation (for those who aren't into Windows ways of putting
things Zeromq is access memory that i
Sure I will get right on it.
-Mikael
> Mikael,
>
> Thank you very much for this patch. Would you also create an issue at
> the 0MQ github repository at http://github.com/zeromq/zeromq2/issues?
> This is a nice way of ensuring the patch won't get lost, and also to
> document the issue so others
Hi
I kept getting runtime errors from my SCL enabled STL library in MSVC 2008 SP1
due to the way select.cpp implemented its erase of retired fd's.
I've implemented a patch and the STL library no longer complains of any errors
in my tests. However this has only been tested on 32-bit Windows so
Trying again, I must look before I send the patch. This time not in reverse :P
Still licensed under MIT/X11 too.
> I am using the zeromq library in a Unicode Windows environment and to
> get 2.0.7 to cleanly compile I had to apply the attached patch. I have
> also added what I guess would be need
<> Hi
I am using the zeromq library in a Unicode Windows environment and to get 2.0.7
to cleanly compile I had to apply the attached patch. I have also added what I
guess would be needed for Mingw to work with the same settings, but I haven't
tested it yet (I don't have Mingw installed atm).
38 matches
Mail list logo
