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

Comments

Re:PIrates rejoice

[Tiberius_Fel]

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.

DCC isn't so good but

[Rosco P. Coltrane]

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.

Re:DCC isn't so good but

[TekPolitik]

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.

It was also designed when Internet pipes were a lot thinner and far more overloaded than they are today. One major university in Sydney (UTS) had a 48kbit pipe for the entire campus. The network was also a lot less reliable - dropped packets were commonplace. When sending a file at full speed over this kind of network, you had a greater risk of timeouts in the network aborting the connection.

There was also the issue that back then the Internet was an entirely academic network, and a lot of the people running it did not approve of the IRC protocol.

The file transfer facility was also only a sideline. The primary purpose of IRC networks back then was <horror>chat</horror>. If you're sitting around chatting anyway you can afford to wait a while for your file transfer to complete.

When you're dealing with overloaded pipes, and trying to fly below the radar, and speed is not considered important, throttling your file transfer well below capacity by requiring and waiting for acknowledgements seems like a pretty good idea.

There was even a facility in IRCII where you could reduce the packet size if your connection was dodgy enough.

Also the way the protocol worked, it was a matter for implementers to decide whether the sender would wait for the acknowledgements at all. A sender could shove the entire file down the pipe if it wanted. The acknowledgement was in the form of the number of bytes the recipient had read. The recipient had no idea what the size of the packet was (and had no reason to care). If the sender transmitted without regard to acknowledgements, it looked no different to a file transfer where the packet size was the size of the file.

The protocol was designed for its day, but that was what, 1991? The net has changed so that perhaps some of the design decisions are no longer appropriate, but that doesn't make the protocol flawed - just out of date. Most of the other protocols have been updated since then too. RFC822 became RFC2822. RFC821 became RFC2821. I think FTP had resume capabilities added too. The IRC protocol itself seems to have been updated every other week. It's about bloody time the IRC client developers got together to update DCC as well, but that doesn't reflect on DCC's design at the time, merely on changing needs.

I also think the complaint that the original protocol was "not extensible" is amusing since their DCC2 protocol is precisely an extension to and compatible with the original DCC protocol.

Re:What's the difference?

[hey]

RTFA...

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

IRC-Junkie.org Article

[szemeredy]

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.

Re:I've got an idea

[undertow3886]

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.

File name and size information ...

[dougmc]

The current dcc protocol isn't *that* bad -- it's very similar to ftp's protocol. It's biggest problem is that it can't work in both directions (send and receive) through a NAT or a firewall that won't let you open a listening port and have somebody else connect to it. So if you're behind a NAT, you can receive a file but can't send one.

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.

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.

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.

Re:What's the best way to organize?

[semafour]

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?

We use a mailing list for most of our communication. That way people can read and reply whenever they want, and there is a public archive available.

...and the second part

[ewe2]

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.