Discussing: DCC2 protocol announced

DCC2 protocol announced

Sunday, April 25 2004 by Asmo

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.

At Sunday, April 25 2004, codemastr (IP: Hidden ) commented:

Lets how mirc and bitchx do _not_ join the project. It sounds horrible! Like viruses? DCC2 will help you get them! Why? Well, according to the spec, the filename is not sent over IRC. So when you accept a connection, you have _no_ idea what is being sent to you. Is it poem.txt? virus.exe? You don't know! To find out, you must accept the connection. So instead of being able to maintain a list of blocked extensions, you must now click "accept" then your client will block it. Real fun. Furthermore, that means, that guy now has your real IP. That means +x has become useless.

Furthermore, the doc was apparently written by people who just make things up as they go. For example, they invented their own, wrong, format for an IPv6 IP. For example, a v4 mapped IPv6 address is illegal, good plan!

Establishing the connection, then switching to SSL? Good plan, that way you can't use SSL's identity verification features.

This is by far the worst DCC rewrite I've ever seen, and I know I'll do everything I can to prevent it from going forward. If you like viruses and exploits, DCC2 is for you, otherwise, I'd say stick with regular old DCC.

At Sunday, April 25 2004, codemastr (IP: Hidden ) commented:

Ok I read it over again and now I understand it. The filenames can pass over IRC, but do not have to. See, this protocol lets you send multiple files in a single transfer. In that instance, it doesn't send the filename over IRC. Instead, it sends the size of an XML file that it transfers to the receiver. The XML file contains all the filenames and sizes.

For most clients, they'll send the filename, the people who want to spread viruses however, will use the Multi option so that the filename is hidden from the user. That makes this even worse. Because it means 99% of the time it will show the file, but not all the time. So that means people will develop a habit of clicking without thinking and viruses will continue to spread.

At Sunday, April 25 2004, DanSmith (IP: Hidden ) commented:

Hi Codemstr

I read your post and would like to clear a few things up. The main goal of the connection negotiation draft is adding ipv6 and security to not just file transfers, but any type of direct connection. This includes whiteboards, direct chat, multiplayer games, etc. Think of it as a way to negotiate the connection you are about to create.

First, during the connection negotiation on IRC an encryption layer can be specified. The clients then connect using that protocol, and if SSL3 or something similar is chosen, certificates can be exchanged. There is no "switching" as you suggest.

About the format for IPv6 addresses, that is legal ABNF format according to the RFC 2373. The format allows zero?’s to be compressed, see section 2.2. The ABNF was copied from RFC 2372 appendix B. Perhaps we can make a reference to this to make it clearer?

As for you comments on file transfers, there are two proposed file transfer types currently on the dcc2 web site. Your remarks on virus spreading are a user and irc client issue. There is no requirement that a client implement the multi-transfer protocol as it is independent of the connection negotiation.

We do appreciate your input, please keep it coming so we can create a better draft. Thanks!

Cheers,
Dan

At Sunday, April 25 2004, codemastr (IP: Hidden ) commented:

"Your remarks on virus spreading are a user and irc client issue."

Well if you don't want to deal with virus/exploit problems, then I guess it's up to someone else. And I'm going to make it up to me. I've already talked it over with the other Unreal coders, and they agree that this draft proposes way too many security risks to be useful. We will not help contribute to further spreading of viruses on IRC. As a result, Unreal will ship with a module that disables DCC2 support. Any DCC2 CTCP request will be rejected. We, as members of the IRC community, feel it is our responsibility to stop the spread of viruses, not to help it. And we will not support a protocol that makes it easier for viruses to spread.

Yes, it is a user issue. But in case you haven't noticed, users are stupid. Otherwise you wouldn't see "Type $decode(..........) to stop spam" and 50 people doing it. Or "Visit www.fake.com/virus.exe for free porn" and 50 people doing it. Yes it's a user issue, but the user's are not smart enough to deal with it. Therefore someone else has to, and if you (the DCC2 people) refuse to, then I guess someone else has to step up to the plate.

Pretty much, from what I've read, everything the DCC2 protocol sets out to do is not going to happen. DCC sends will be faster? How, by having to send a 500 byte XML header to send files? You speed things up by compressing formats, not by adding more header data.

ACKs are unnecessary? Yeah, TCP does indeed support ACK itself. But UDP doesn't guarantee that things will arrive. So you need ACK because DCC2 (for whatever reason) has decided that UDP is needed. So if someone uses UDP, well now you have the potential for incomplete and corrupt file sends, that doesn't sound good to me.

NAT traversal? Yeah good plan. How do you know if the NAT IP is valid?

In my mind, about 80% of this draft needs to be rewritten before it would get my support.

At Monday, April 26 2004, codemastr (IP: Hidden ) commented:

'Threatening to "disable" someone elses specification because of a personal dislike for it, inconveniencing people will cause major problems and is not the correct way to represent yourself to the IRC community. '

Thank you for ignoring my post. It has NOTHING to do with my personal dislike. It has to do with me not wanting to SPREAD VIRUSES. There is a big difference.

"I agree with Anonymous, Its like usermode +I in Unreal, it was removed because 'You didnt like it', unlike other admins who used it responcibly."

Unreal was illegal in several nations because of +I. Furthermore, it has NOTHING to do with our personal opinions. We received an average of 10 complaints a day about +I. Also, when you start paying for UnrealIRCd, then I'll let you tell me how I should and shouldn't code it. We did not want the legal liability that came with +I. We make no money from Unreal. If we get sued, Unreal disappears. We figured that would be a bigger inconvenience to our users than not having +I.

Also, no one things about the "inconvenience" that DCC2 will cause to IRC Admins. UnrealIRCd allows admins to block DCC sends they don't want on their servers (warez, porn, etc.). DCC2 prevents them from having this feature.

Also, actually read my posts rather than saying "it's a flame" and ignoring it. I said A MODULE. That means you can turn it off if you want DCC2. I'm merely saying that I think everyone should disable DCC2 and I'm giving them that option.

Now I remember why I hate making public posts... people like at one sentance out of 50 and take it out of context and tear it apart. You won't hear anything further from me, my mind is already made up on DCC2.

At Monday, April 26 2004, Anonymous Unregistered (IP: 62.254.0.48 ) commented:

You stated you would write a module to completely disable DCC2 support on unrealircd servers. completely disable means to remove the ability for DCC2 chat and secured chats, as well as file sends. I didnt hear such heated discussion when it came to the original DCC protocol. Admittedly there are module in existence to filter dccs but they do not filter ALL dccs (including chats, and file sends of perfectly legitimate file types).

I have signed up to the list for DCC2 and will attempt to add my own suggestions on the implementation of this protocol, to make it better for all.

As for the support for +I, i dont believe the legality issue at all. Many countries have issues with encryption, and will not allow export or import of encryption technologies, i'd be more concerned about this (and SSL support in ircds) than a few usermodes which are NOT illegal in the country where the software is produced. If a piece of software ie legal where it is written, you have nothing to worry about and the responsobility for this lies solely with the person who chose to download and compile the software and install it on their machine, not with the developer who is out of the juristiction of any laws in said countries. But, IANAL (as frequently said on slashdot) and any rant i have ends here. We will agree to disagree on this subject, new protocols should be encouraged, not stimeyed, and i believe it is your role, and other developers role to provide feedback and steer this project, correcting any issues you see, rather than just shooting it down.

At Monday, April 26 2004, Syzop (IP: Hidden ) commented:

I'm personally certainly not very PRO-XML. Obviously, since there have been several DCC security bugs in the past, if you go using XML you can count on all kinds of new fun bugs comming up (huge lists, xml parser bugs, etc) but ah well..
Also, irc clients would suddenly require an xml parser. I guess my main point is that (especially when compared to current DCC) it's quite complex without gaining much.
It also sounded as 'you suddenly receive an XML file' and after that the client asks if you want to download the files... Thus disclosing the IP address first and asks later etc.
But now I look better it seems like a file list where you can choose from? Still be sure to pay attention to the disclosing of IP addrs... For example at UnrealIRCd we have mode +x that 'hides' hosts (other ircds might have similar things), if then the client goes auto-connecting without asking that's just horrible.
Second, the virus/trojan issue... this is quite a problem. We have a deny dcc system in unreal and recently also implemented a spamfilter by which we can block(/kill/gline/etc) on specific patterns (in for example dcc), this is very powerful as you can imagine since by just adding a rule a whole trojan can be stopped on a server... But if you are going to send all those filenames etc off-irc then this is no longer possible (bit like making the whole world use PGP encrypted mail and then no longer be able to use anti-spam and anti-virus software).
Then we have NAT, I'm not sure... I guess I'll just not comment on that.
The error messages.. this seems to be mentioned as one of the big advantages, but what's wrong with /notice nick Error: connection refused?
IPv6 and SSL/TLS, those are the 2 nice things I can see, but for at least IPv6 you could just extend the current protocol.
Overall, you shouldn't be surprised that quite some people won't like this idea. It's not that these people are against any development... On the contrary, probably quite some people would like a new modern dcc standard... but then it shouldn't be done like this... As mentioned several times the mIRC, bitchx and irssi developers don't seem involved... it seems a bit stupid to go create such a spec without contacting those major clients that represent like 95% of the IRC population.

At Monday, April 26 2004, Anonymous Unregistered (IP: 62.254.0.48 ) commented:

I'm not too keen on XML either, but maybe this is something that can be addressed.

XML isnt too much of an overhead on windows as to my knowledge windows systems which are packaged with IE5 and above come with an XML parser built into them anyway, so no need for extra stuff like libxml etc if you use this.

In some respects it may be a good idea to not transmit the filenames over irc. Trojans, virii etc are a client side issue, not a server side issue, and should be dealt with by re-education of users and not cocooning them in an environment that disguises the true risks of being online and also being on IRC. In many ways it is not the responsibility of an irc admin to deal with this by blocking things at the server level, as this generates extra support issues and can annoy users. Admittedly sometimes it is a good idea to do this but only when a file transfer can be 100% gauranteed virulent (e.g. blocking ALL executable file types = bad).

The one thing i really want to see come out of this is SSL/TLS support which is really essential for communicating with an IRC Bot (which is what my client primarily is)

At Monday, April 26 2004, Anonymous Unregistered (IP: 67.38.163.211 ) commented:

One important thing to point out with regards to the reasons for a DCC2 standard. There really is no such thing as a DCC standard. There are some usenet posts, implementations, and informal papers written by those who have implemented clients, but there is nothing that can be called a standard. I would say the major goal of DCC2 is to create such a standard through the IETF.

Also, it was mentioned that DCC file transfers can be done over UDP, and that is the reason for the ACKs built into DCC. Maybe I am missing something, but I have never heard of this. UDP packets, in addition to not being reliable (and therefore requiring ACKs to acheive reliability), is also not guaranteed to be ordered. Just because one UDP packet is sent before another, doesn't mean they will arrive on the other end in that order. The original DCC does not address this ordering issues, because file transfers are never done over UDP. That's because in order for that to be possible, a "transmission control protocol" would have to be written on top of UDP. I guess it might be named TCP...

At Monday, April 26 2004, Anonymous Unregistered (IP: 67.38.163.211 ) commented:

I can understand the concern that server admins have about not being able to block files when they can't see the names. Doing so will still be possible when sending a single file.

Our main goal with the muti option, where files are listed not over IRC, but over a direct connection before transferrering, is to allow for a case like this: I just get back from vacation and I have 53 pictures I want to send to my friend. Currently, I have to send 53 DCC requests. With DCC2, I have to send one.

If anybody has any alternative ideas on how to do this without 53 messages going over IRC, I would be happy to know. Or is the opinion just that this shouldn't be possible?

Thanks!

At Monday, April 26 2004, Anonymous Unregistered (IP: 65.32.50.18 ) commented:

I believe viruses can be spread by kazaa, email, ftp, dcc floppy disks and even web pages. How is an irc server not seeing the file name going to be any more of a problem? A better question, how is an irc server seing a file name going to stop the virus? Not many virus writers name their file bigassvirus.exe or anything similar. Since this is a planned improved protocol, instead of claiming you intend to ban the new protocol outright before even seeing it, a better solution would be to offer as a suggestion that a hook be placed in it so client authors (or antivirus authors) can hook in a virus scanner or even spam filters. I prefer the new dcc2 have as little to do with irc as possible so that it could be used with IMs or other things. Besides, as I understand it, the problem with viruses spreading on irc has more to do with exploits of a certain unnamed but popular irc client. If the user is downloading files and running them without checking for viruses or clicking on links with an unprotected web browser, there is nothing an irc network can do to stop that. I welcome a new dcc protocol, especially the ssl and ipv6 support. With the ability to also scan files as you download them, all the better. If an irc network somehow manages to block it, I would just use a differnet network.

At Monday, April 26 2004, codemastr (IP: Hidden ) commented:

Perhaps I should clarify. I do not intend to block DCC2 in general. Just the filesends, and more specifically, only those file sends using the multi-send feature.

Oh and regarding SSL encryption, you need to look carefully. First, you'll note the *nix version of Unreal includes NO encryption technology. Second, you'll note the Windows version that does is only distributed on non-US servers for legal issues. So we are indeed concerned about the legal ramifications of SSL.

And UDP, indeed, I have no idea why it mentions UDP. But they decided to support UDP, TCP, and SCTP (I've never seen the last one used for anything). Why? I have no idea. But definately, UDP causes numerous issues that the draft doesn't even come close to addressing.

And about the 53 pictures... wouldn't fserve prevent you from having to worry about it? But there is an advantage to having 53 seperate connections. They can happen at the same time. I didn't look into the draft too much, but I don't see anything about the multi-send feature allowing the transfer of 2 files at the same time (i.e., two seperate sockets). So yeah, it makes it "easier" but it doesn't make it "faster" (faster in a throughput sense meaning total time to complete 53 sends rather than the transmission rate which should be almost exactly the same). I agree, multi-sends are a nice addition (in some rare instances), but lets face it, 99% of the people are going to be using this for warez, not for vacation pictures. Personally, when I have pictures I want to share, I put them on the web, I don't send dozens of huge jpg files to everyone I know. And I assume most people do the same (hence the numerous ePhoto album sites). So in my mind, multi-sends are going to be used more for abuse than anything else. Plus, I hate the XML idea. Why can't it just do a simple header?
FILE ID "FILE.EXT" "DESC" SIZE CRC

Why must it be a cumbersome XML format which then requires (especially on Linux) applications to make use of expat/libxml for DCC? And additionally, XML eats more bandwidth than the little simple format I just included. No ... junk to worry about.

At Monday, April 26 2004, codemastr (IP: Hidden ) commented:

Not many virus writers name their file bigassvirus.exe or anything similar. Since this is a planned improved protocol

No they don't. However, they do use extensions such as .jpg.pif, .jpg.exe and .html.exe, or .html.vbs and other such things that don't normally appear in valid filenames. Blocking those extensions can seriously limit the number of viruses being spread over IRC.

As for a hook in IRC clients. I don't know how many times I had suggested that in mIRC. However, everytime, I was the only one who supported it, all the users said it was stupid/wasteful and so it was never added. One of many reasons why I no longer use mIRC... But, can an IRC network stop viruses? Of course not. Can it slow their spread? Hell yes! And that's what I want. If we could stop, even 10% of viruses, that would be a tremendous victory.

Oh and about a network "somehow managing" to block it. I already have, I have the code in my head at the moment that can and will block all DCC2 multi-file sends. Chats, and single file sends will work as normal, multi sends will not.

At Monday, April 26 2004, Syzop (IP: Hidden ) commented:

I still wonder about those multi-file-sends...

Besides the XML stuff (which seems to be disliked by several client developers too now)...

Will the "receiver" be able to choose which files he/she is going to download? If so (which seems to be the case) then it looks more like a fileserver, so then why does it "suddenly" receive an incomming request.. isn't it then more logical to do like current fileservers and send a request TO the person offering files?
And else, why not use the current protocol + a queue on the client side... If the files are large enough (=take >2-3s) then this is not a problem, if there are numerous small ones then I wonder why you don't just zip them?

Also, what's the client going to show? "Incomming multifile request... Unfortunately we've NFI what files are offered, but hey have a look?". Or is the client going to connect automatically? (wow, that would be great! [/sarcasm]).

At Tuesday, April 27 2004, codemastr (IP: Hidden ) commented:

Yeah, well there is an RFC for IRC... see how standard IRC is? I mean every server is exactly the same! Oh wait, nope, no servers are the same. There is an old saying, "the nice thing about standards is - you have so many to choose from"

Is there a formal IETF document that defines DCC? Nope. Is it needed? I don't think so. Everyone implements pretty much the same DCC protocol. I say, just standardize what we have now, with the "enhancements" meaning, you standardize the use of " " around a filename to support spaces, add support for IPv6 and encryption (EDCC). I don't see why you need to start from scratch and add things that are unneeded and almost impossible to make work (e.g. DCC over UDP).

At Tuesday, April 27 2004, Anonymous Unregistered (IP: 67.38.163.211 ) commented:

After reading the draft again, I now understand what it means for UDP to be allowed. I thought it was weird, too, at first, but now it makes sense.

Nobody is proposing that UDP be used for transferring files or for chatting. The draft that contains the TCP/UDP option is for connection negotiation. Theoretically, ANY type of connection can be negotiated; file transfers, chat, chess, checkers, tic tac toe, whatever. It's possible that somebody may wish to negotiate for UDP.

One thing I can think of is a "typing indicator". Say I have a good friend I talk to a lot, and I want to know when he is typing a message (like how most IM programs tell you that). I could send a DCC request indicating as much; he would let me know if it's OK for me to have that information, and if so, I would start listening for UDP packets. His client would send UDP packets indicating his current keyboard status. Ta daaa.

Of course, that is not standardized, but it could be.

At Tuesday, April 27 2004, Limerick (IP: Hidden ) commented:

Well, not to attack anyone, but from a technical standpoint, I'm not sure I can agree with many of the "If it isn't broke, don't fix it" arguments offered. Although some of you have legitimate points, a couple presented this mentality alone by itself. Now if that means, you want to go back to the world of 56K modems, since they certainly weren't broken, be my guest. But people trying to improve on a protocol is hardly call for that particular strain of argument. I happen to agree that this method does seem to be less sound than it should be in regards to using xml's and the like when simple text strings would work and be more efficient. However, that does not stop the "If it isn't broke, don't fix it" mentality from being a potentially dangerous threat to innovation.

At Tuesday, April 27 2004, tmcalee (IP: Hidden ) commented:

I am not against changes or enhancements to the protocol. However, like codemastr, I think more work needs to be done on the protocol first. But, that is why it is an open group. I don't know when or if the issues he pointed out will be resolved, although there probably won't be much support for it until they are. Being the author of an IRC client, I can tell you that it wouldn't find its way into my client until I was sure any security concerns was addressed.

Don't take codemastr's comments as flames. His wording might be harsh, but thats probably not out of line given the potential risks. He was pointing out legitimate concerns, and people who ultimately use this protocol should be happy that somebody was taking the time to do that. They can be found now by people like codemastr, or found later by people who want to spread viruses to unsuspecting people. Take your pick.

At Tuesday, April 27 2004, Asmo (IP: Hidden ) commented:

Uhm, no need to start flames now :)

OK, codemastr's way of communicating might look a bit flamatory at times, but he did brought up valid points. And not just that, but two of the developers of DCC2 already pointed out here the concerns of codemastr are real, and worth/necessary to look into.

I for one would look forward to a new DCC protocol, ofcourse with any security concerns worked out of it. But as I said before, with the reputation the developpers have of DCC2 I'm sure they agree any flaws int hat area should be worked out before it goes "final".

To write such a post about codemastr wheer yu acuse him of flaming, without doing anything to contribute to the discussion is actually flaming yourself.

PS: for all those who keep using a nick without having registered a nick on IRCJunkie: your nick will not show, and your IP will show as explained clearly around the form :)

At Saturday, May 1 2004, codemastr (IP: Hidden ) commented:

I'm happy you're glad I'm gone; I'm happy I'm gone! I'm much happier with Klient than I ever was with mIRC. And, if everyone was so happy about me leaving, how come I got dozens of people asking me not to leave? But thank you for telling me I don't know what I'm talking about. After all, I've only been working with the IRC protocol for 4 years, you surely know more about it than I do. The DCC2 people, however, seem to disagree with you. If they thought I was just some raving lunatic, they would have just ignored me. Instead, they listen to and value the opinions of myself and others. I'm also sorry that I put my users' security concerns above adding new features.

"I heard a lot of people wanted you to resign staff of UnrealIRCD."

I know that if I asked you to tell me who said these things you couldn't, because you just made them up. If people want me to resign, well then let them come tell it to my face; having them come through you, doesn't prove a thing.

I think adding tons of features to mIRC is cool? I don't care at all about what features mIRC has; I don't use it! Secondly, if you read my old posts on mIRC.com, I, more often than not, was *against* adding new features.

I don't think I know everything, I never said I know everything. I, just like every human being, am probably wrong more of the time than I am right. But, when I make comments, I don't resort to insults and swearing, I argue with facts. People who feel the need to insult others (like you did to me) are generally the kind of people who think they know everything. Also, if Unreal is so unstable, why is it major companies use it? I'm sure ICQ installed Unreal on their IRC server because it was unstable? I'm sure Sega Dreamcast decided to run it because it was unstable? In fact, Unreal is quite stable. There are many server with several thousands of users running Unreal, and they have been running for several months without a crash. So again, you lie. And about complaining DCC2 isn't good enough? Perhaps you should learn what the RFC process is. RFC stands for "Request for Comments." It means they WANT people to say "this isn't good, it should be changed." Right now, DCC2 isn't even an RFC, it is a draft. That means it's not final. If you subscribe to the DCC2 mailing list, you'll see that changes and suggestions are being made everyday! And, the DCC2 group doesn't yell at anyone for this, they *value* input.

Furthermore, you have the nerve to accuse me of flaming? Did you read your post? You attacked me, you attacked my work, you insulted me, you insulted my work, and you made up complete lies about me. And you have the nerve to say I'm the one flaming?

Also, I like how you hide behind an anonymous name. When I post things I know people will disagree with, I could hide my identity, but I don't. I'm man enough to stand behind my opinions. Why don't you do the same?

At Sunday, May 9 2004, Anonymous Unregistered (IP: 195.130.142.250 ) commented:

"I just get back from vacation and I have 53 pictures I want to send to my friend. Currently, I have to send 53 DCC requests. With DCC2, I have to send one. If anybody has any alternative ideas on how to do this without 53 messages going over IRC, I would be happy to know."

The solution to this is very simple. Do you transfer "folders" over KaZaA? Over MSN? Any other IM program? No, you send an ARCHIVE that contains the folder and everything in it, COMPRESSED and possibly even secured. See those keywords there? Very important advantages that you're missing out on by your single-sided approach.

The multiple-file-send thing is really a Bad Idea. KISS! (Keep It Simple, Stupid!) Single-file transfers have proven sufficient in so many cases, and most OS's these days have archiving tools prepacked so I don't see a problem there either..