View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002912 | unreal | ircd | public | 2006-05-10 21:04 | 2013-05-06 06:19 |
| Reporter | tabrisnet | Assigned To | |||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | resolved | Resolution | no change required | ||
| Platform | Linux/x86 | OS | Debian Linux | OS Version | testing |
| Product Version | 3.2.5 | ||||
| Summary | 0002912: zlib compression, user protocol | ||||
| Description | Chances are, this would be more likely something to come out of ircu than Unreal. I'd like to see client-level compression. like -z3 or something (as in, not very high compression, save on CPU and all). I admit that it's a CPU eater, but so is SSL. I do however think that it might be useful, esp to mitigate [receive] floods, or cases where there is a lot of traffic in a channel (cases include diagnostic data, oper-notices [connect,nick-change, etc]). Right now it is possible to get so much data that one gets flooded off. Anything to save bandwidth would be interesting. Now, obv, it has the disadvantage that it's 'one more vector for crash bugs' if not implemented carefully, but I would guess that SSL might do this too. Heck, I bet that XDCC Catcher and Bottler might like this ;), not that I like those programs very much (ban on sight). | ||||
| Tags | No tags attached. | ||||
| 3rd party modules | |||||
|
|
This would require some kind of client/server protocol negotiation, which unfortunately does not yet exist in irc... |
|
|
Dunno. I could see that. or I could see it as just another extension on PROTOCTL. if client supports it, it sends ZIP in protoctl. if the server doesn't know ZIP, it should ignore it, right? Or is that not guaranteed in client protocol? Likely the biggest problem is finding client ppl to imp it. X-Chat might. mIRC will if they see enough reason. XDCC-Catcher and such might add it if they know about it. |
|
|
I may be misunderstanding how PROTOCTL works. My understanding is that it works something like this (does not include 005): Client sends PROTOCTL <allflagsclientsupports> Server sends PROTOCTL <allflagsserversupports> client reads what server says, checks it against its own list Server reads what the user says, checks it against its own list. Anything server doesn't know, it a) ignores b) doesn't activate [duh] Anything client doesn't know, it a) ignores b) doesn't activate [duh] kinda like C's #pragma. It's supposed to ignore what it doesn't know (Tho i think that warning is probably ok). If that doesn't work, we add ZIP to our 005. Client sees it, sends PROTOCTL ZIP back, and we then have a STARTZIP cmd/msg. After that, the stream runs through zlib. |
|
|
wait. does server send protoctl on login? even if it doesn't, we can replace it on the 005 for the server-sent PROTOCTL. I've probably been digging into the server protocol too much lately to notice that PROTOCTL isn't sent by the server to the client. |
|
|
I have a novel idea. Instead of all this hoohah with protoctl (we dont currently do this for SSL, unless im wrong) We currently have a specific port for SSL connections. My idea is like this: Add a new port option. We have: * SSL * Clientsonly * Serversonly Why not just make ZIP another port option, like SSL? No client breakage that way.. currently if you try to connect to SSL ports in regular mode, you get disconnected. It should be the same way with ZIP. |
|
|
Tis a possibility, tho it would be nice if it was more common than that. After all, 90% of users don't know SSL is a possibility, let alone know which networks they go to have SSL ports or what portnums they are. It would be rather useful if we switched SSL to TLS instead, and used STARTTLS. Then discovery would be automatic and transparent, same as we have in SMTP. SSL is a separate port b/c as it was designed, it does not support delayed negotiation. You need TLS to do that. |
|
|
[quote]It would be rather useful if we switched SSL to TLS instead, and used STARTTLS. Then discovery would be automatic and transparent, same as we have in SMTP.[/quote] Unreal should already support TLS, if it doesn't that's a bug. But your STARTTLS idea is terrible. It's more than just encryption, it's for authentication too. What you're saying is, you want the client to just start sending data to the server, before it's authenticated, because once STARTTLS is sent, we'll authenticate it. That's bad. I don't want to send anything more than I have to to a server that may or may not be who it claims to be. |
|
|
I find that authentication with SSL, for IRC networks, is a joke. We all end up using self-signed certs b/c we don't have the budget to pay for a wildcard certificate to cover all of our leaves. Thus we end up telling our users to turn off the 'complain if selfsigned' option, just so it doesn't bitch. I understand the reasons that the SSL system is the way it is, but it's still damned annoying for most of us. Hell, does mIRC even support checking the SSL cert if the fingerprint matches? X-Chat might b/c it doesn't suck, but I doubt mIRC does. I use irssi, and afaik it doesn't either. |
|
|
fwiw I agree that we shouldn't be sending NICK and USER, let alone PASS before we have SSL setup, if only for the encryption we want. Thus it may be that the client would have to request it early in registration. This may even make it impossible. But adding Yet Another Port for this purpose seems to be no better. We'd end up with an SSL + ZIP port, SSL only port, and ZIP only port, in addition to our normal client port. SSL may be badly suited to late negotiation, esp for the reasons codemastr indicated (the need to authenticate and encrypt early) but ZIP can be negotiated late, even if the sooner we do so the better (like, before we join a channel with 300 users). |
|
|
[quote]Thus we end up telling our users to turn off the 'complain if selfsigned' option, just so it doesn't bitch.[/quote] In general, you might be right. But I've run Unreal on some corporate systems where confidential info is routinely discussed. These were at companies with fierce competition. The companies required that SSL be enabled and required all clients to verify the authenticity of the server. They didn't want to chance a competitor managing to DNS hijack one of their IRC servers and potentially leak trade secrets. So for most people it might be a joke, but for others it's important. About ZIP though, that's something that should be able to be turned on/off at will. As you said, it makes sense when I'm going to join a bunch of channels. But at other points it doesn't. Remember, zipping is a CPU hog, we don't want to use it if we don't have to. So the client and server should be able to negotiate it at will imo. And that's something IRC doesn't support at present. Several proposals exist (draft-baudis-irc-capab, draft-mitchell-irc-capabilities, handshake, proto, capab, protoctl, etc.) but none have really ever gained steam. I'm really not ready to implement a system like this until 1.) a working design exists and 2.) it has the potential of being accepted by the IRC community. If I were to implement it, I'd probably go with the mitchell spec as it has the best chance of succeeding imo. |
|
|
zLib possibly not a cpu eater , it eats memory because of hash tables. We can use simple lzr compression with hashed some most used word index can be faster and cpu memory less. |
|
|
I've added it as a TODO item for 3.3*. For me personally and pretty much everyone in this country (NL) I don't see much use since they all can cope with the bandwidth, but.. there are other countries / internet connections where this can make a lot of sense (oh and.. smartphones? [gprs, etc], that's pretty popular these days as well and you often are charged per KByte). So I wouldn't mind seeing this implemented.. As an option of course. "How?" is another question of course ;) I don't plan to be personally very active on this field, but if someone likes this feature and wants to negotiate with IRC clients' authors that also find it a good idea, perhaps we can see it implemented then :P |
|
|
LZO anyone? It's available GPL. |
|
|
I think this "feature" is unneeded, as IRC is already a horridly low bandwidth protocol and used to run fine on 14.4kbps.. The development will go towards less horrid charges for mobile traffic, imho. I don't think this is something Unreal needs to wander into as the benefit is very little and people would end up writing custom proxies instead for special mobile clients, and this is a more viable solution, imho. I'm moving this to 3rd party wishlist of this reason. |
|
|
fwiw, I understand that SSL can use zip internally. that might require less work, to just require that all ppl who want it use SSL too. |
|
|
Does SSL for clients already do gzip? if so, this bug could probably be closed (and I'd just have to check that the clients will enable it). |
|
|
TLS provides this and we should really be pushing clients to use TLS anyway... |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2006-05-10 21:04 | tabrisnet | New Issue | |
| 2006-06-04 20:23 |
|
Note Added: 0011849 | |
| 2006-06-04 21:14 | tabrisnet | Note Added: 0011851 | |
| 2006-06-04 21:18 | tabrisnet | Note Edited: 0011851 | |
| 2006-06-04 21:19 | tabrisnet | Note Edited: 0011851 | |
| 2006-06-18 18:55 | tabrisnet | Note Added: 0011982 | |
| 2006-06-18 19:16 | tabrisnet | Note Added: 0011983 | |
| 2006-06-19 01:46 | Zell | Note Added: 0011985 | |
| 2006-06-19 20:48 | tabrisnet | Note Added: 0011988 | |
| 2006-06-19 20:57 | tabrisnet | Note Edited: 0011988 | |
| 2006-06-19 21:01 |
|
Note Added: 0011989 | |
| 2006-06-19 21:07 | tabrisnet | Note Added: 0011990 | |
| 2006-06-19 21:59 | tabrisnet | Note Added: 0011991 | |
| 2006-06-19 22:04 | tabrisnet | Note Edited: 0011991 | |
| 2006-06-19 23:32 |
|
Note Added: 0011993 | |
| 2006-07-10 11:16 | darkelf | Note Added: 0012064 | |
| 2006-11-12 15:14 | syzop | Note Added: 0012651 | |
| 2006-11-12 15:14 | syzop | Status | new => confirmed |
| 2007-06-10 11:39 | tabrisnet | Note Added: 0014309 | |
| 2007-06-12 15:01 |
|
Note Added: 0014342 | |
| 2007-06-12 15:02 |
|
Relationship added | child of 0003284 |
| 2007-06-19 19:19 | tabrisnet | Note Added: 0014390 | |
| 2010-05-24 07:07 | tabrisnet | Note Added: 0016102 | |
| 2013-05-06 06:19 |
|
Note Added: 0017489 | |
| 2013-05-06 06:19 |
|
Status | confirmed => resolved |
| 2013-05-06 06:19 |
|
Resolution | open => no change required |
| 2013-05-06 06:19 |
|
Assigned To | => nenolod |
