"/If you're doing 100,000 encrypted messages, you're not worried about
microsecond synchronization./" : the point is I would prefer to do it
with 100 messages rather than 100,000.
"/I'm curious to see what you're cooking... :-)/" : my project deals
with security with no compromise. Most of my clients will be in essence
paranoid, so I shall take into account back doors suspicions, by
principle. So my cooking is a modified CURVE with no loss of security
towards Daniel J. Bernstein's CurveCP, but a deep neutralization of
possible back-doors with some perpendicular security.
.....Just to make you a little more curious and hungry I hope ;-)
Le 10/10/2013 18:49, Pieter Hintjens a écrit :
On Thu, Oct 10, 2013 at 6:38 PM, Laurent Alebarde <[email protected]> wrote:
In order to avoid sending a burst of say 100,000 messages, I need a
"precise" synchronisation. Thus something close to the kernel looks like a
good choice. As I want the test to be portable, zmutex has looked a good
candidate for synchronizing the bursts. You know, it is just for testing,
not a library functionality.
I don't know if I can reach a sufficient time resolution with PUB/SUB, but I
am going to try.
pub-sub over inproc: will probably give you as good resolution as you
need (and note the general rule about not optimizing a case you
haven't even tested yet). If you're doing 100,000 encrypted messages,
you're not worried about microsecond synchronization.
As usual, just make a plausible solution and improve it gradually as
you find issues to fix. There's little point in (and indeed, some
strong arguments against) trying to make it perfect from the start.
I'm curious to see what you're cooking... :-)
-Pieter
_______________________________________________
zeromq-dev mailing list
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
_______________________________________________
zeromq-dev mailing list
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
