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."
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/
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....
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
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.