> I recently brought case-insensitivity on the development hub, 
> and it's a 
> noticeable issue. According to Tim Bray at 
> http://dotnetjunkies.com/WebLog/sriram/archive/2004/11/18/3270
> 7.aspx#32794, 
> I'm sure hub authors will love that when they were (only partially 
> tongue-in-cheek) suggesting $ClientID sorts of mechanisms to save CPU 
> time because parsing the tag is just so horribly slow. I'm mostly 
> indifferent with mild bias against mandatory case-insensitivity for 
> unrelated reasons, but best to know this beforehand.

Indeed. Case sensitive it is then...

> 
> Further: I would like not only for encryption, but for some traffic 
> shaping-resistance in the form of, in Gargoyle's words, doing SSL [or 
> TLS] from the outset. It even looks pretty practical speedwise; I had 
> OpenSSL report to me the 1000s of bytes per second processed 
> under each 
> cipher on an Athlon 800MHz, and came up with:
> 
> type             16 bytes     64 bytes    256 bytes   1024 
> bytes   8192 
> bytes
> rc4              63129.39k    71440.23k    73317.55k    74151.25k 
> 74446.17k
> aes-128 cbc      18007.45k    18464.32k    18731.69k    18789.38k 
> 18814.29k
> aes-192 cbc      15695.25k    16054.23k    16252.50k    16294.57k 
> 16315.73k
> aes-256 cbc      14000.18k    14208.81k    14367.32k    14404.27k 
> 14417.92k
> 
> It drastically exceeds a 10Mbit/s connection's capacity, and 
> that of a 
> 100Mbit/s connection less drastically, even on a slow machine, and in 
> the former case by an order of magnitude even when not using 
> 100% CPU as 
> that test allowed. However, I fully expect that should encryption 
> appear, 100Mbit/s users might disable it as I gather they reasonably 
> commonly disable zlib compression.

The problem is not the client, the problem is obviously the hub...

> 
> I'm unsure as to the nicest way of avoiding ever revealing 
> the presence 
> of a DC connection by encrypting from the very first packet of a 
> connection, but I would strongly support that. 
> http://l7-filter.sourceforge.net/technicaldetails and 
> http://l7-filter.sourceforge.net/protocols provide insight 
> into what the 
> programs you mention can detect, and thereby means of defeating them. 
> I'm fairly ignorant of the capabilities and limits of the commercial 
> versions.

Well, as I see it, we simply create an ssl tunnel which is(?) indistinguishable from a http ssl tunnel (apart from the fact that the connections stays up for a long time...). Ssl in theory might be a bit overkill with certificates and all, but since speeds seem ok, that's probably the way to go for hubs that want to offer encryption as well...c-c encryption is a matter of changing protocol in the ctm, and also there ssl fits the profile...
Trying to make the plaintext protcol look like something else is wasted effort imho - at some point we'll be sending data which is unique to our protocol, and all it then takes is a patch to the network filter to block it...

/J

-- 
DC Developers mailinglist
http://3jane.ashpool.org/cgi-bin/mailman/listinfo/dcdev