Instant chats and central servers
raistlin at tacorp.net
Wed May 9 18:13:14 UTC 2001
Jason Slagle - CCNP - CCDP
Network Administrator - Toledo Internet Access - Toledo Ohio
- raistlin at tacorp.net - jslagle at 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:
> > No.
> 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:
More information about the NANOG