mailing list archives
RE: Instant chats and central servers
From: Jason Slagle <raistlin () tacorp net>
Date: Wed, 9 May 2001 14:13:14 -0400 (EDT)
Jason Slagle - CCNP - CCDP
Network Administrator - Toledo Internet Access - Toledo Ohio
- raistlin () tacorp net - jslagle () toledolink com - WHOIS JS10172
/"\ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
\ / ASCII Ribbon Campaign . If dreams are like movies then memories
X - NO HTML/RTF in e-mail . are films about ghosts..
/ \ - NO Word docs in e-mail . - Adam Duritz - Counting Crows
On Wed, 9 May 2001, David Schwartz wrote:
I don't see how that can be. A P3-600 can RC4 encrypt over 60MB/sec in 64
byte blocks. That figure drops to only 45MB/sec in 8 byte blocks. This is a
slight overstatement because cache effectiveness is increased by repeatedly
encrypting the same stream.
If a chat server with a P3-733 has a throughput of, say, 8MB/sec out and
3MB/sec in, encryption on all that traffic would eat less than 15% of the
CPU. There would be some memory usage to store all the encryption/decryption
state information but memory is cheap.
Our tests with RC4 seem to indicate different. Maybe we just have a bad
implementation of it. Maybe it's time to look at it more.
If you used a dual processor machine and separated the actual chat layer
from the I/O layer, you could put the encryption in the I/O layer. This is
actually not that terribly hard to hack into Ircd.
Nope, and that seperation is planned, but probably not until we do out
I think you're simply assuming that it's infeasible but you haven't
actually tried it or done the math. We've done it with ConferenceRoom, and
the encryption load is so low as to be almost lost in the noise.
As I said, we can encrypt now between servers (The code is in). Based on
the math we saw testing this functionality, it didn't seem feasible to do
it to the clients, but as I said, maybe we just had a bad implementaion.
:puts it on the list of things to try: