RE: Instant chats and central servers

[Jason Slagle <raistlin () tacorp net>]

-- 
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:

> > 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
full rewrite.

>       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:

Jason