On 11/17/2010 08:41 PM, Brian Granger wrote:
You want to make sure that the IO thread is free enough to keep the
underlying network pipe full. If the IO thread starts to do CPU bound
work to the point where it can't maintain max network throughput, that
will kill performance. But, the idea
On Thu, Nov 18, 2010 at 9:07 AM, Martin Sustrik sust...@250bpm.com wrote:
Right. And both actually boil down to the same model:
Application-thread - Encryption(device)-thread - I/O-thread
You can even think of running several encryption threads in parallel
(parallelised pipeline a.k.a.
Hi Brian,
Summary: even if we can figure out how to make message level security
bulletproof, there are some serious performance issues.
Great analysis!
At the moment I see 2 solutions to the performance problem:
1. Create an inproc encrypting/decrypting device, send the messages
through the
Hi,
(you don't really want CPU bound work in IO threads)
I don't actually see why this would be a problem.
But maybe a special encryption thread could solve this issue.
This thread would encrypt the message and then send it to
the IO thread which does not have to mind about if the
message is
On Nov 17, 2010, at 0:15, Martin Sustrik sust...@250bpm.com wrote:
Hi Brian,
Summary: even if we can figure out how to make message level security
bulletproof, there are some serious performance issues.
Great analysis!
At the moment I see 2 solutions to the performance problem:
1.
On Wed, Nov 17, 2010 at 1:23 AM, Diablo 666 thediablo...@hotmail.de wrote:
Hi,
(you don't really want CPU bound work in IO threads)
I don't actually see why this would be a problem.
But maybe a special encryption thread could solve this issue.
This thread would encrypt the message and
Hi,
We (the pyzmq devs) have been thinking and talking a lot about security
lately and Min has been prototyping various ideas. I wanted to report back
on our findings as I think they are relevant to the larger security
discussion.
For the record, there are 3 main security approaches that are
