Talk:Direct Client-to-Client

DCC2

DCC2 is in the works (Slashdot Article on DCC2). While this might fall under the "extensions" of DCC, it looks like it's going to be a complete replacement. Perhaps it should be mentioned in the article? -- Kowh 01:53, 26 Apr 2004 (UTC)

I'm adding a note to the effect that DCC FSERVE is only available under mIRC. It doesn't exist in X-Chat or anywhere in the ircII family. --Cuervo 01:36, 9 Apr 2005 (UTC)

Correct me if I'm wrong, but I don't think FSERV is a separate service at the DCC level, but rather uses CHAT (or in place of that, CTCP) and SEND/XMIT together to create something else. This kind of scripting is not exclusive to mIRC either. I've updated the article to reflect this. --Andyluciano 22 Aug 2005, 05:33 (UTC)

That is correct. FSERV uses a DCC CHAT based interface for the user to find and request files, which are then send via a normal DCC SEND. And, yes, it has been implemented under other clients (in some cases as scripts, and in some (as with mIRC) as a built-in feature).

As for DCC2: it has been in the works for several years, and shows little sign of going anywhere. At the core, it is a good idea to completely scrap DCC—which is an atrocious, poorly (and barely) planned mess. I don't remember its particulars, but it would be better to replace it with a far more robust architecture, with a minimum (perhaps utilising scp or other existing secure tunneled protocol) rather than just a new handshaking method. (But i digress, and this is not the place.) —StationaryTraveller 14:03, 21 July 2006 (UTC)

CTCP vs. CTCP reply

Since the reply to a PRIVMSG should not be another PRIVMSG, a CTCP reply is implemented with a NOTICE. But is the DCC ACCEPT reply, which is a reply to a reply, a CTCP message or a CTCP reply? I guess that it should be a reply, and implemented with NOTICE, but it would be nice to have this confirmed.

The IRC part of the DCC handshake is done entirely as CTCP non-replies (i.e. PRIVMSG). Thus, the ACCEPT and RESUME messages disobey the RFC-1459 guidelines about automatic responses (intended to prevent runaway loops between robots). Automatic responses (of any kind) to NOTICE are also forbidden (which is why IRC servers don't complain if you send a NOTICE to a non-existant target). So dialogues between robots are limited to a single exchange. One of the basic stupidities of DCC is that it does too much via IRC, rather than getting to its direct connection ASAP, and finishing its handshaking there. —StationaryTraveller 14:15, 21 July 2006 (UTC)

XMIT

The only specification I could find for XMIT was an old working draft, which expired long ago. Was XMIT never accepted as a standard?

"DCC standard" is an oxymoron ;) —StationaryTraveller 14:18, 21 July 2006 (UTC)

Programming libaries

Shouldnt we include something about programming libraries avaliable to code such DCC stuffs??

DCC Send Exploit

The DCC Send Exploit is less than helpful to me, as I'm supposedly affected after being notified by IRC ops. In particular, this part, "Replacing [character argument] with a string of 14 or more characters ..." doesn't mean a thing; where is this [character argument] supposed to exist?

I feel the description here is ok except for that unexplained part, but a link with more details would be really helpful. —Preceding unsigned comment added by Jimcooncat (talk • contribs) 09:35, 6 February 2008 (UTC)

I believe this part isnt really even needed anymore at all in the case of mIRC, I have heard that the exploit does not exist any longer in the latest versions of mIRC. This is why I keep removing it, but others revert my changes, very annoying. --Speeddemon8803 (talk) 18:36, 14 May 2009 (UTC)