Ämne:RE: SV: [dcdev] Anyone still alive?
Från:"Jacek Sieka" <[email protected]>
Till:"'Direct Connect developers'" <[email protected]>
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.I recently brought case-insensitivity on the development hub, and it's a noticeable issue. According to Tim Bray at
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...
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.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.
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