Skip to content

Direct Client-to-Client

Direct Client-to-Client (DCC) (originally Direct Client Connection ) is an IRC-related sub-protocol enabling peers to interconnect using an IRC server for handshaking in order to exchange files or perform non-relayed chats.

Version
v1 · 2026-09-28 · History
Domain-specific #
8994
Domain group
Applied Sciences & Engineering
Origin domain
Computer Science & Software Engineering
Subdomains
Network Protocols, Internet Relay Chat → Computer Science & Software Engineering

Core Idea

Direct Client-to-Client is treated here as the recurring computer_science_and_information identity summarized by this source-grounded definition: Direct Client-to-Client (DCC) (originally Direct Client Connection ) is an IRC-related sub-protocol enabling peers to interconnect using an IRC server for handshaking in order to exchange files or perform non-relayed chats.

Direct Client-to-Client (DCC) (originally Direct Client Connection ) is an IRC-related sub-protocol enabling peers to interconnect using an IRC server for handshaking in order to exchange files or perform non-relayed chats. Once established, a typical DCC session runs independently from the IRC server. Originally designed to be used with ircII it is now supported by many IRC clients.

Some peer-to-peer clients on napster-protocol servers also have DCC send/get capability, including TekNap, SunshineUN and Lopster. A variation of the DCC protocol called SDCC (Secure Direct Client-to-Client), also known as DCC SCHAT supports encrypted connections. An RFC specification on the use of DCC does not exist.

For Direct Client-to-Client, the abstraction is narrower than the article's general subject matter: a positive case must preserve Direct Client-to-Client (DCC) (originally Direct Client Connection ) is an IRC-related sub-protocol enabling peers to interconnect using an IRC server for handshaking in order to exchange files or perform non-relayed chats. Retaining only the name, a familiar example, or a downstream effect is insufficient. The specialist roles and tests remain anchored in computer_science_and_information, which is why this identity is domain-specific rather than prime.

How would you explain it like I'm…

Meet, Then Talk Directly

Imagine a big chat room where everyone talks through a helper in the middle. Two people can use the chat room just to say "let's connect," and then they send files or talk straight to each other without the helper passing every message. That's Direct Client-to-Client.

Chat Room Handshake Link

Direct Client-to-Client, or DCC, is part of IRC, an old system for online chat where messages normally go through a server. DCC lets two users use the IRC server only to set up a connection, like a quick handshake. After that, their computers connect directly to each other to send files or chat privately, without the server passing along their messages. The direct connection keeps working on its own even without the server's help. It started with a program called ircII and is now supported by many chat programs.

IRC Direct Peer Connection

Direct Client-to-Client (DCC), originally called Direct Client Connection, is a sub-protocol related to IRC (Internet Relay Chat). In normal IRC, every message is relayed through a server. With DCC, two clients use the IRC server only for handshaking, exchanging the information needed to connect, and then open a direct peer-to-peer connection to transfer files or chat without relaying. Once set up, the DCC session runs independently of the IRC server. It was first designed for the ircII client and is now supported by many IRC clients, and even some clients on napster-protocol networks. A variant called SDCC (Secure DCC), or DCC SCHAT, adds encryption. Unusually, there is no RFC specification describing DCC.

 

Direct Client-to-Client (DCC; originally Direct Client Connection) is an IRC-related sub-protocol in which two peers use the IRC server solely for handshaking and then establish a direct connection for file exchange or non-relayed chat. After setup, a typical DCC session runs independently of the IRC server, so data no longer passes through the relay. Originating with the ircII client, it is now widely supported by IRC clients, and some napster-protocol peer-to-peer clients (TekNap, SunshineUN, Lopster) also implement DCC send/get. The SDCC (Secure DCC) variant, also called DCC SCHAT, supports encrypted connections. No RFC specifies DCC.

Structural Signature

Sig role-phrases:

  • Defining carrier — It allows the initiation of a DCC connection by IP address, without the need of an IRC server.
  • Constitutive relation — When compared to sending messages normally, this reduces IRC network load, allows sending of larger amounts of text at once, due to the lack of flood control, and makes the communication more secure by not exposing the message to the IRC servers (however, the message is still in plaintext).
  • Operating condition — The CTCP protocol was implemented by Michael Sandrof in 1990 for ircII version 2.1.
  • Recognition evidence — The DCC protocol was implemented by Troy Rollo in 1991 for version 2.1.2, but was never intended to be portable to other IRC clients.
  • Admissible variation — Messages that begin with an ASCII 001 (control-A, represented below by ^A) and the word ACTION, and are terminated by another ASCII 001, are interpreted as emotes: ^AACTION waves goodbye^A.
  • Characteristic consequence — DCC Whiteboard is initiated with a handshake similar to DCC CHAT, with the protocol replaced by.
  • Failure boundary — Data is sent to the client in blocks, each of which the client must acknowledge by sending the total number of bytes received in the form of a 32-bit network byte order integer.

What It Is Not

  • Not the whole field of computer_science_and_information. The node requires the specific identity stated by Direct Client-to-Client (DCC) (originally Direct Client Connection ) is an IRC-related sub-protocol enabling peers to interconnect using an IRC server for handshaking in order to exchange files or perform non-relayed chats.
  • Not an over-broad reading. When compared to sending messages normally, this reduces IRC network load, allows sending of larger amounts of text at once, due to the lack of flood control, and makes the communication more secure by not exposing the message to the IRC servers (however, the message is still in plaintext).
  • Not an over-broad reading. The traffic will go directly between the users, and not over the IRC network.
  • Not an over-broad reading. The original specification for the handshake did not allow the receiver to know the total file size nor to resume a transfer.
  • Not automatically Sun RPC. Retrieval proximity does not establish equivalence; the two identities must be compared by carrier, operation, and failure boundary.

Scope of Application

Direct Client-to-Client applies literally inside computer_science_and_information wherever the source-defined carrier and relation can be established. Its documented habitats include:

  • DCC Relay. This method can be used by XDCC channels to fill their XDCC bots from other XDCC channels.
  • Common DCC applicationsDCC CHAT. The CHAT service enables users to chat with each other over a DCC connection.
  • Common DCC applicationsDCC CHAT. Once a connection is established, the protocol used for DCC CHAT is very simple: users exchange CRLF-terminated messages.
  • DCC SEND. It is common practice to add the file size as a last argument: DCC SEND.
  • DCC XMIT. The XMIT service is a modified version of DCC SEND that allows for resuming files and cuts down on wasteful traffic from the ACK longs.
  • DCC XMIT. If the receiver does not implement the protocol used, it will send back a CTCP reply of the format: ERRMSG DCC CHAT unavailable.

Outside computer_science_and_information, the name should be retained only when these same operational conditions survive; otherwise the comparison belongs to the broader parent Pattern or should be marked as analogy.

Clarity

A clear use of Direct Client-to-Client names the carrier, the operative relation, and the conditions under which the source treats the identity as present. The minimal definition is Direct Client-to-Client (DCC) (originally Direct Client Connection ) is an IRC-related sub-protocol enabling peers to interconnect using an IRC server for handshaking in order to exchange files or perform non-relayed chats. The strongest recognition evidence in the frozen account is: The DCC protocol was implemented by Troy Rollo in 1991 for version 2.1.2, but was never intended to be portable to other IRC clients. A report should distinguish that evidence from a proxy, consequence, or common implementation. It should also state the qualification When compared to sending messages normally, this reduces IRC network load, allows sending of larger amounts of text at once, due to the lack of flood control, and makes the communication more secure by not exposing the message to the IRC servers (however, the message is still in plaintext). so that a reader can reproduce the classification rather than infer it from topical resemblance.

Manages Complexity

Direct Client-to-Client compresses multiple computer_science_and_information details into a stable diagnostic relation. The source shows both the central mechanism—when compared to sending messages normally, this reduces IRC network load, allows sending of larger amounts of text at once, due to the lack of flood control, and makes the communication more secure by not exposing the message to the IRC servers (however, the message is still in plaintext).—and the practical consequence—dCC Whiteboard is initiated with a handshake similar to DCC CHAT, with the protocol replaced by. This compression makes cases comparable while leaving parameters, conventions, exceptions, and evidential quality explicit. It is lossy by design: local history and implementation details may be omitted only when they do not alter the defining relation.

Abstract Reasoning

  1. Type the carrier. Identify the computer_science_and_information entities to which the claim applies.
  2. State the relation. Use the source-grounded identity: Direct Client-to-Client (DCC) (originally Direct Client Connection ) is an IRC-related sub-protocol enabling peers to interconnect using an IRC server for handshaking in order to exchange files or perform non-relayed chats.
  3. Check operation and conditions. The CTCP protocol was implemented by Michael Sandrof in 1990 for ircII version 2.1.
  4. Demand recognition evidence. The DCC protocol was implemented by Troy Rollo in 1991 for version 2.1.2, but was never intended to be portable to other IRC clients.
  5. Test variation. Change an implementation or setting while preserving messages that begin with an ASCII 001 (control-A, represented below by ^A) and the word ACTION, and are terminated by another ASCII 001, are interpreted as emotes: ^AACTION waves goodbye^A.
  6. Run the collapse test. Remove the defining operation; if the label still seems equally apt, only a topic or correlate was retained.
  7. Reduce cautiously. When the specialist conditions cannot be carried, route the residual comparison to Pattern.

Knowledge Transfer

Within the home domain. Knowledge about Direct Client-to-Client transfers literally when a new case preserves the same carrier type, relation, and recognition test. This method can be used by XDCC channels to fill their XDCC bots from other XDCC channels. The CHAT service enables users to chat with each other over a DCC connection.

Beyond the home domain. No canonical parent is asserted for Direct Client-to-Client. An outside case receives the specialist name only when the same typed roles and rejection conditions can be filled literally; otherwise the comparison remains an analogy pending later graph densification.

Examples

Canonical

The send-ahead extension relieves this problem somewhat by not waiting for the acknowledgements, but since the receiver still has to send them for every block it receives, in case the sender expects them, it is not solved completely. This case is canonical because it supplies a concrete carrier and lets the defining relation be checked rather than merely named.

Mapped back: carrier → the entities in the documented case; operation → Direct Client-to-Client (DCC) (originally Direct Client Connection ) is an IRC-related sub-protocol enabling peers to interconnect using an IRC server for handshaking in order to exchange files or perform non-relayed chats; recognition evidence → The DCC protocol was implemented by Troy Rollo in 1991 for version 2.1.2, but was never intended to be portable to other IRC clients

Applied / In Practice

In the case of the protocol, the XMIT server will, upon receiving a connection, send a 32-bit time t in network byte order, representing the file's modification time. The applied case shows how the identity is used under a second setting or qualification while keeping the same operative relation.

Mapped back: changed setting → DCC XMIT; invariant → Direct Client-to-Client (DCC) (originally Direct Client Connection ) is an IRC-related sub-protocol enabling peers to interconnect using an IRC server for handshaking in order to exchange files or perform non-relayed chats; boundary → the case exits the class when when compared to sending messages normally, this reduces IRC network load, allows sending of larger amounts of text at once, due to the lack of flood control, and makes the communication more secure by not exposing the message to the IRC servers (however, the message is still in plaintext)

Structural Tensions

T1 — Stable identity versus admissible variation. When compared to sending messages normally, this reduces IRC network load, allows sending of larger amounts of text at once, due to the lack of flood control, and makes the communication more secure by not exposing the message to the IRC servers (however, the message is still in plaintext). The tension matters because emphasizing only one side either dissolves the identity or overstates what the evidence and domain conventions warrant.

Diagnostic: Which changes preserve the defining relation, and which replace it?

T2 — Recognition versus proxy. The traffic will go directly between the users, and not over the IRC network. The tension matters because emphasizing only one side either dissolves the identity or overstates what the evidence and domain conventions warrant.

Diagnostic: Does the cited evidence establish the identity or only a correlated sign?

T3 — Definition versus implementation. The original specification for the handshake did not allow the receiver to know the total file size nor to resume a transfer. The tension matters because emphasizing only one side either dissolves the identity or overstates what the evidence and domain conventions warrant.

Diagnostic: Is the observed implementation constitutive, optional, or merely common?

T4 — Scope versus overextension. The send-ahead extension relieves this problem somewhat by not waiting for the acknowledgements, but since the receiver still has to send them for every block it receives, in case the sender expects them, it is not solved completely. The tension matters because emphasizing only one side either dissolves the identity or overstates what the evidence and domain conventions warrant.

Diagnostic: Can every claimed application fill the same typed roles without metaphor?

T5 — Transfer versus domain accent. It allows the initiation of a DCC connection by IP address, without the need of an IRC server. The tension matters because emphasizing only one side either dissolves the identity or overstates what the evidence and domain conventions warrant.

Diagnostic: Does the receiving case instantiate Direct Client-to-Client literally, co-instantiate Pattern, or only resemble it?

T6 — Autonomy versus reduction. When compared to sending messages normally, this reduces IRC network load, allows sending of larger amounts of text at once, due to the lack of flood control, and makes the communication more secure by not exposing the message to the IRC servers (however, the message is still in plaintext). The tension matters because emphasizing only one side either dissolves the identity or overstates what the evidence and domain conventions warrant.

Diagnostic: What does Direct Client-to-Client distinguish that the broader parent Pattern leaves together?

Structural–Framed Character

Direct Client-to-Client is structural-leaning. Its structural side is the repeatable organization summarized by Direct Client-to-Client (DCC) (originally Direct Client Connection ) is an IRC-related sub-protocol enabling peers to interconnect using an IRC server for handshaking in order to exchange files or perform non-relayed chats. Its framed side is the computer_science_and_information vocabulary that fixes the carrier, evidence, exceptions, and admissible transformations.

Evaluative weight: the identity can be stated descriptively even when applications carry practical stakes. Human-practice dependence: the source-grounded carrier determines whether the relation exists independently or is constituted by a practice. Institutional origin: disciplinary conventions stabilize the name and test. Vocabulary portability: The CTCP protocol was implemented by Michael Sandrof in 1990 for ircII version 2.1. Import versus recognition: literal transfer requires the same mechanism; shape alone is analogy.

Its portable skeleton is Pattern. Its character: a recurring specialist identity whose thin organization can be abstracted, while its operational meaning remains domain-bound.

Structural Core vs. Domain Accent

What is skeletal. Direct Client-to-Client (DCC) (originally Direct Client Connection ) is an IRC-related sub-protocol enabling peers to interconnect using an IRC server for handshaking in order to exchange files or perform non-relayed chats. The stable skeleton is the typed relation expressed in that definition and the entry's recognition and collapse tests. The source identifies these operative conditions: It allows the initiation of a DCC connection by IP address, without the need of an IRC server. When compared to sending messages normally, this reduces IRC network load, allows sending of larger amounts of text at once, due to the lack of flood control, and makes the communication more secure by not exposing the message to the IRC servers (however, the message is still in plaintext). It further constrains recognition and variation through: The CTCP protocol was implemented by Michael Sandrof in 1990 for ircII version 2.1. The DCC protocol was implemented by Troy Rollo in 1991 for version 2.1.2, but was never intended to be portable to other IRC clients.

What is domain-bound. computer science and information supplies the operative entities, technical vocabulary, warrants, and exceptions that make Direct Client-to-Client literal. Its documented scope includes the condition that This method can be used by XDCC channels to fill their XDCC bots from other XDCC channels. Another bounded application condition is that The CHAT service enables users to chat with each other over a DCC connection. These are not decorative examples; they determine which carrier and evidence can fill the abstraction's roles.

Why no parent is asserted. Removing those specialist details does not currently yield one live catalog node that is a necessary genus for every instance. The entry is therefore approved as unparented rather than attached by topical resemblance. Its collapse evidence remains specific—Messages that begin with an ASCII 001 (control-A, represented below by ^A) and the word ACTION, and are terminated by another ASCII 001, are interpreted as emotes: ^AACTION waves goodbye^A—and future graph densification may discover a defensible relation only if it preserves that boundary.

  • Approved unparented node. No current live node supplies a defensible necessary genus or structural prerequisite for Direct Client-to-Client. The reviewed identity is: Direct Client-to-Client (DCC) (originally Direct Client Connection ) is an IRC-related sub-protocol enabling peers to interconnect using an IRC server for handshaking in order to exchange files or perform non-relayed chats. The accelerated suggestion was declined because topical or lexical similarity does not establish hierarchy; the node is admitted without a parent pending later graph densification.
  • Related reasoning operations. Evidence, representation, comparison, classification, transformation, or evaluation may participate in particular cases, but participation does not make any one of them a necessary parent of every instance.

Neighborhood in Abstraction Space

Direct Client-to-Client sits in a sparse region of the domain-specific corpus (85th percentile for distinctiveness): few abstractions share its structure, so a faithful description tends to retrieve it precisely.

Family — Unclustered & Miscellaneous (2551 abstractions)

Nearest neighbors

Computed from structural-signature embeddings · 2026-10-08

Not to Be Confused With

  • Pattern. The parent omits the specialist differentia. Tell: Can the case establish Direct Client-to-Client (DCC) (originally Direct Client Connection ) is an IRC-related sub-protocol enabling peers to interconnect using an IRC server for handshaking in order to exchange files or perform non-relayed chats?
  • Sun RPC. The ONC remote-procedure-call system encoding typed requests with XDR and transporting them over UDP or TCP to registered network services. Tell: Which entry's carrier, operation, and failure condition are satisfied?
  • Domain application protocol. A domain-specific hypermedia interaction contract that narrows a general application protocol into the resources, link relations and state transitions of one distributed business process. Tell: Which entry's carrier, operation, and failure condition are satisfied?
  • Unix Domain Socket. Unix Domain Socket is a recurring operating systems, interprocess communication identity in which processes on one Unix-like host exchange streams, datagrams, or sequenced packets through a local socket namespace. Tell: Which entry's carrier, operation, and failure condition are satisfied?
  • A measurement, proxy, or consequence. Those may provide evidence without being the identity. Tell: Would Direct Client-to-Client remain present if the detector or downstream effect changed?
  • A metaphorical analogue. A similar shape outside computer_science_and_information lacks the specialist mechanism. Tell: Do the native roles transfer literally, or only the parent Pattern?

References

  • Frozen Wikipedia discovery revision: https://en.wikipedia.org/wiki/Direct_Client-to-Client (revision 1327110617).
  • Preserved source candidate: https://www.troy.rollo.name/opensource.html
  • Preserved source candidate: https://web.archive.org/web/20181116085439/https://www.troy.rollo.name/opensource.html
  • Preserved source candidate: https://www.kvirc.net/doc/doc_dcc_connection.html
  • Preserved source candidate: https://www.irchelp.org/protocol/ctcpspec.html
  • Preserved source candidate: http://download.ircii.org/historical/unsorted/clients/unix/ircii/ircii-2.1.4e.tar.gz
  • Preserved source candidate: https://groups.google.com/group/alt.irc/msg/fc5de46e023d5ffe
  • Preserved source candidate: https://www.irchelp.org/irchelp/rfc/dccspec.html
  • Preserved source candidate: https://www.mirc.com/help/html/index.html?dcc.html

The frozen Wikipedia revision is discovery provenance. The retained source set was reviewed for identity, formal or operational relation, and scope. The encyclopedia's structural synthesis is bounded to those claims; a thin authority surface is recorded as a nonblocking source-strengthening repair rather than concealed.