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
With all the attacks on p2p networks, DCC may be more needed than ever.
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/
Let's dump DCC (which isn't that bad, except for the TCP ports) and FTP, and come up with a decent transfer file replacement One that doesn't need 10,000 free ports, special firewall tuning, works through a layer of encryption without problems, but still doesn't generate a lot of overhead.
Fred
"A fool and his freedom are soon parted"
-RMS
They revamped the whole protocol but Ratios weren't mentioned even once. Are they sure this is for IRC?
Is DCC used by anyone else but file pirates and music traders? I mean really. Come on. Don't lie. Oh sure, you know a guy who has a cousin with a good friend that has a girlfriend whose brother distributes his folk music on IRC but besides that, anyone else using DCC for legit transfers?
Strange women lying in ponds distributing swords is no basis for a system of government.
does this mean i'll be able to get warez even faster?
Why not kick in some p2p as well? If you're going to download a x00 mb file, then you might as well be a good neighbor and share some of that upstream bandwidth you've got there. And if p2p is not an option, why not just take a random OS FTP server, stuff it in an IRC client, let the initial connection go through the server and let browsing & data-transfer go through a direct connection.
Seems to me that writing a file transfer protocol ( Where have I heard that before? ) would be like reinventing the wheel. I mean, it's useful, sure. It's also been around for ages, as well.
Hate me!
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 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....
A group of IRC client programmers announced today they are working on a new direct connection protocol named DCC2 of which the draft can be found here.
"The DCC2 community, a group of leading IRC client developers, today announced an initiative to create standards that will make establishing direct connections between IRC clients easier. The group will also work to standardize the protocols used to transfer files and text messages between clients once a connection has been established, allowing for a simpler and more feature-rich user experience" developer Dan Smith wrote in a press release to IRCJunkie. Smith is also the lead developer of the windows IRC client dIRC.
Besides dIRC, the developers of the next IRC clients are involved with the new DCC2 protocol; Visual IRC, Ircle, KVirc, Bersirc, Chatzilla and OrnateIrc. We asked Smith why key clients like mIRC and BitchX are yet not present in this list.
"I have not talked with the authors of the clients you listed personally. Our group is following a standards process and would appreciate input from anyone who expresses interest! I am personally impressed with the large number of major client authors (Windows, Unix, Mac) who have already expressed interest and are helping to write our drafts."
The current DCC protocol is known to be lacking in clarity where it comes down to finding out why something fails to work.
"The main goal of our negotiation draft is to identify connections that are more likely to be established. The second goal is to allow the clients to know exactly why a connection failed, instead of a silent failure" Smith explained their goal to improve in this area as well.
For users behind a NAT who are not really known with networking issues this is a well known source of problems. Smith explains how the DCC2 protocol would handle in case of problems in this situation: "... direct connections between two ipv4 users behind NAT/firewalls will still fail if they do not have ports forwarded for connections. However both clients will know why the connection failed and can take appropriate action, such as opening ports using UPNP or notifying the user that their network setup prevents connections. With the addition of IPv6 to direct irc connections, users can map ipv6 addresses inside of their NAT, and use ipv6 in the connection negotiation process as well. I highly recommend sixxs.net for anyone interested in ipv6 technology."
"File name and size information never needs to pass over IRC", the website of the DCC2 protocol reads. Some networks have taken action against channels where music files are being shared over DCC. We asked Smith if this will prevent the network to see what is being transmitted between the clients.
"The main goal of the file transfer draft is to allow multiple files/directories to be transferred concurrently, along with additional metadata such as file checksums, descriptions, etc. The fact that this file metadata is listed out of band, and possibly encrypted, keeps file transfers private between two irc clients. The direct connection negotiation still takes place over irc."
The DCC2 protocol will be compatible with the currently used DCC protocol. "While DCC2 is a completely new way to publicize connection data, we have added a compatibility layer to work with historic dcc. In short, we found that many clients ignore unused tokens after historic dcc messages. The DCC2 tokens can be appended to the historic dcc commands, and if both clients support dcc2 then a connection negotiation takes place", Smith explains.
It is expected that during the coming summer the first clients will come with DCC2 at a experimental stage.
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
IRC may be ugly, but like Windows, it's here because everybody uses it.
Its massively cross-platform-available and easy to integrate into messaging apps.. That's worth a lot more than the costs incurred by its kludged technology
I have been a user for about 10 years. This ends Feb 2014. The site's been ruined. I'm off. Dice, FU
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!
How to fuck up any software project: Add XML
For bonus fuck ups, write it in Java.
Ha!
How dcc works: if you're sending a file, you open a listening port, then send your IP and port to the remote host via a CTCP message. The remote host connects to that IP and port, and accepts the file.
To fix the send/receive via a NAT problem, one could merely make an extension (or just a seperate sending command) where the sending machine requests that the receiving client open a host and port and then the sender connects to it. It wouldn't be too difficult to implement, but it might require that a ctcp message be sent back from the receving client. We've been talking about this for over a decade. The hardest part would be to talk the other client authors to implemenet it.
One other, less commnon problem -- that IP that is sent comes from your hostname in many cases, so on a multi-homed box it's often wrong. Here is a pseudo-fix that's just under 10 years old for ircII.
But make no mistake here -- the *only* reason one would need to avoid sending file name and size information over irc would be to avoid censorship or logging done by the irc servers. It's just metadata, and a few bytes of it -- the servers can handle it without any problems.In fact, it would be nice if the new dcc protocol (if it's ever completed and widely implemented, which I doubt, based on my experience with how irc stuff is done) could support sending small files directly through the servers with no additional TCP connections. It would be *very* slow (thanks to flood control -- perhaps 100 bytes/second tops) and would put a larger load on the servers, but it would allow two clients behind two different NATs to send files to each other when nothing else would. Wouldn't be practical for .mp3 files, but it would for .ircrc files. Of course, the server admins would hate the mere idea, and if people used it a lot they'd add code to the servers to find and block it, K-line the users, etc.
"We are not stupid here, we know what IRC and DCC is mainly used for -- just read the other posts on this topic. Please don't insult our intelligence here on Slashdot."
If it is efficient pirates will use it as will porn peddlers. Who the heck cares what DCC or heck even IRC are mainly used for? I use IRC for tech support from like minded users. I have also benefitted from people sending me a config file or document. At the end of the day the I am better for the tech being there even if people like you want to raise your noses in the air and haughtily dismiss IRC as a bastian of pirates to the exclusion of all else.
My real problem with your sanctamoneous argument is it may lead others in authority to stifle a source I benefit from. Your arguments are like those of the antigun nuts. Guns are used in crimes lets ban guns. Meanwhile I live in a society that has tight legal controls on guns and yet people are still being shot in the streets. So what then is the solution? Is it to search everyone or maybe ration out movement? If it can be used to pirate software it will be used to do so. So go after the pirates and leave the rest of us alone.
M. Kenery
Honestly, I don't think XMPP is going to help a lot. I am not an XMPP guru, but from what I've seen it looks less efficient than IRC.
The main problem with IRC seems to be the enormous load that is put on servers, mainly caused by using the servers to relay client to client messages.
There is a solution to this problem: DCC. Using DCC, clients connect directly to one another, and thus spare the servers. With a little extension, DCC can also be used to implement chat rooms client-side, so that server relaying of messages is only needed for initially connecting the clients to one another.
Of course, we could design a protocol specifically for the purpose of connecting clients to one another, and I think that would be a good idea. Jabber and IRC both do a lot more than this, which makes them, in a sense, bloated.
Please correct me if I got my facts wrong.
Anime Music Videos, demoscene compo-paks, and other nicities are often found on P2P networks too... it's all those people trading their WaReZ and illegal MP3Z and DVD rips on it that are giving it a bad name.
Yaaddaa yadda yyadda. Everything can be used for ill or good.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
Depends on what town you grew up in....
My home town of 8000 people has to be the IRC capital of the world with 100's of people chating on IRC at anyone time. It started way back in 96 and the channel is still going strong today. Best of all its pretty damn stable, its been years since there has been a conflict. Back in the day I must admit to taking the town channel on several occations.
IRC is still being used by chat by isolated groups.
God, root, what is the difference?
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".
Probably because you didn't look hard enough.
--Riley, dIRC developer, Algenta Technical Staff member
If you can read this, then I forgot to check "Post Anonymously".
Taco, you might want to update the story with the link to the second draft, Draft File Transfer Specification. It isn't on the IETF site yet, however.
insecurity asks the wrong question irritation gives the wrong answer