Slashdot Mirror
DCC2 Protocol for IRC file transfers
Joe_Hypnol writes "I just noticed this bit of news over at IRC Junkie. Looks like a bunch of irc client authors (and even more) are putting their heads together to come up with DCC2, a replacement for the the poorly designed DCC IRC file transfer specification. The old protocol was basically based on a usenet post, but this new one is looking like it'll be a full-blown standard. It's currently an IETF internet working draft. Read the press release at DCC2.org."
To replace the poorly designed IRC protocol?
Just curious: when a bunch of smart authors get together to hammer out a new protocol, what's the best way to come to a consensus? Mailing lists? Blog? Wiki?
Here's what I do: Bitty Browser & Andromeda
How about an IETF standard for warez serving bots. I hate learning the different commands for the different bots.
Everyone just joins #consensus.
Well, I for one think this will be quite good. It's very frustrating to try to DCC a document to somebody only to have it fail for a variety of reasons. I look forward to improving this standard. :-)
On the other hand, this does improve the IRC-for-filesharing thing that I've seen... way back in the day before Kazaa, my friends used to pick up their movies etc. from IRC channels... so this will facilitate that, I suppose... possibly not what the authors have in mind.
Join the Empire! http://www.empirereborn.net/
Yeah, that was my thought too. It's very much a case of rearranging the deck chairs on the Titanic.
The IRC protocol is flawed. Not just superficially broken, but horribly, fundamentally broken in numerous ways. As a result it's unreliable (prone to network splits), puts massively unnecessary load on servers, has problems with contention for nicknames, and so on. It really needs complete replacement.
Mind you, now that we have XMPP, there's a strong case for just letting IRC slowly die and having XMPP chat rooms take over.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
Nicknames use SW-ASCII, yes that's right, the swedish variant of 7-bit ascii. That's the reason [ and { are equivalent, as is | and \.
There are no standard encoding. Most people use 8859-1, other languages use, well, whatever they happen to agree on. A number of other channels use UTF-8 which is the best solution (supports all languages) but is not supported by mirc.
Takeovers, splits, need I say more?
Server desync
I don't think DCC is a problem at all. It's all the other crap that needs to be fixed. Once you do, I'm pretty sure implementing good file transfers will be quite simple.
Right now? Considering there is no dcc2 and its still in the works... the same thing that makes Duke Nukem Forever better than original Duke Nukem.
I seriously use DCC for things other than pirating. DCC is commonly used by my particular group to pass along logs, interesting documents, proposals & updates, et cetera. In a sense you might say it's like P2P - it's used by a lot of filesharers / pirates - but it's not the exclusive domain of those types.
Join the Empire! http://www.empirereborn.net/
Um, yeah. Just about any time I need to send a file to a friend on IRC I would use DCC. For example, "Hey take a look at this logo", or "You need help? Send me your .cc file".
It seems like you have only been exposed to bots using DCC to send you files. You are talking about someone who distributes music on IRC or whatever, when in reality DCC is more than a means for bots to offer files. Normal users send files too... it's just like sending an email attachment.. you use those don't you?
Sure people do... it goes something like this: :)
boy: hi
girl: hi
boy: asl?
girl: 19/f/someplace
boy: pic?
girl: [dcc send]
Of course feel free to replace girl with [boy pretending to be girl]
I really, often do wonder why the RIAA (not to mention the MPAA and the BSA) has overlooked IRC for so long. 9/10ths of the channels on any of the reputable networks are dedicated to illegally distributing mp3z, moviez, warez or pr0n (or some combination thereof).
Now, dcc2 will make all that so much easier; which I guess is a boon for the various networks' profits, but at what moral cost?
It's easy to dismiss DCC as a flawed protocol. Sure it has its shortcomings, but remember, it was designed before the internet started to become firewalled to death. I remember, until perhaps 1997, DCC was just fine and easy to use, and almost never gave us any trouble. Now you have to prep up your firewall, deal with your NAT box, or get the IRC client to take care of it, ...
Here's a quick overview of how a DCC connection is initiated:
- The initiator's IRC client opens a TCP socket, then (let's call him Bob) sends a DCC (CHAT, SEND) request through normal messaging. Basically it's a plain-text message starting with ^A, similar to a CTCP request. Then it listens to the socket.
- The target IRC client (let's call him Joe) gets it, decodes Bob's socket's IP address and port inside the DCC request, and tries to initiate a TCP connection to Bob.
- Once the connection is established, if it's a DCC CHAT, text is sent as-is across the TCP connection back and forth. If it's a DCC SEND, then the file transfer protocol is used over the connection.
Of course, the confusing thing for people who aren't familiar with DCC is that it's the initiator's client that temporarily becomes the server for the contacted client, and not the other way round, like most people are used to, with http for example. So basically, it's people who initiate DCC connections who must open one or more inbound TCP ports in their firewalls, and configure their IRC clients to limit themselves to using those ports.
"A door is what a dog is perpetually on the wrong side of" - Ogden Nash
The current DCC protocol does not address IPv4 vs. IPv6 issues, SSL/
TLS encryption negotiation, NAT and Firewall traversal, or multiple
file/directory file transfers....
Like it or not, pretty damn many use mIRC. Under community members, there's noone from mIRC there. I would hope that is temporary, because DCC really could use replacement. I'm now firewalled off with no incoming ports, two years ago I was NAT'd with no incoming ports.
It leads to extremely stupid things like being able to recieve but not send, even though it is obviously possible since once the connection is established, the data should be able to flow either way. The other big alternative is FTP, which also is horrible at dealing with passive mode.
The hilarious part is that the reason corporations, universities etc. seem to give for it is p2p - when they get around this trivially. On a network, someone will be active and there's no problem. You're only being a major pain in the ass for me when I want to do something with a friend that also has no open incoming ports.
Kjella
Live today, because you never know what tomorrow brings
You can get a program called scponly (works with sftp too) and set that as your guest user's shell. It makes it so they can use sftp, but not log on with plain ssh and get a console. It works great for me.
Sick of people knocking on Gentoo's greatness in completely unrelated
As an IRC Admin, all I have to say is, just fucking wonderful, all IRC needs is a better file transfer method, to bring in more scum, and drag IRC down even more. IRC Stands for Internet Relay CHAT, and while it's nice to have a way to transfer files (like on most IMs), it's gotten out of hand, and it's doing nothing but hurting us chatters on IRC. I like Kazaa, WinMX, and the like as much as anyone else here, but I also love being able to chat on IRC.
When I tell people I use IRC, more and more people say something along the lines of "yeah, much better than kazaa" or "I could never figure it out, so I still use kazaa myself", it's quite sad. ISPs hate IRC, and it's hard to find any that will let you host IRC servers, if not because of it's rep for illegal MP3s, warez, ect, it's cause of the DDoS attacks IRC attracts because of the extra scum file transferring brings.
And now they want to improve DCC, JUST FUCING WONDERFUL!
The point is to let the protocol decide the best way to connect given several options so the user doesn't have to manually try each of the many variants of the DCC command that have been added to the different clients to overcome the problems with DCC (e.g. dealing with NAT).
I do not beleive that dcc2 will have a great difference of quality over the regular dcc but it will have more compatibility.
DCC2 will perform better than DCC in most circumstances. DCC requires ACKs every so often, halting transfer until the ACK is sent from the receiver. Since TCP/IP already guarantees delivery, this part of the protocol is completely redundant, and it can significantly slow down delivery.
They aim to "incorporate new technologies" but I dont see where they are going with this...
DCC2 is both simple and extensible, unlike DCC which, though simple, is not at all extensible. Some functionality that DCC2 could help standardize accross clients are whiteboard sharing, voice/video chat, encryption, IPv6 connections, etc.
--Riley, dIRC developer, Algenta Technical Staff member.
If you can read this, then I forgot to check "Post Anonymously".