CTCP and DCC FAQ - Revision history

Secretagent: /* How does CTCP work? */

Secretagent — Sun, 30 Mar 2008 06:59:25 GMT

How does CTCP work?

← Older revision		Revision as of 06:59, 30 March 2008
Line 25:		Line 25:
	- value = value to be processed by the target's client		- value = value to be processed by the target's client

-	For example, a ping of channel #~~chatx~~ would be:	+	For example, a ping of channel #DareNET would be:

-	<blockquote>PRIVMSG #~~chatx~~ :^APING 866780265^A</blockquote>	+	<blockquote>PRIVMSG #DareNET :^APING 866780265^A</blockquote>

-	This message would be received by all the people on channel #~~chatx~~ but yourself. They would all get this:	+	This message would be received by all the people on channel #DareNET but yourself. They would all get this:

-	<blockquote>:Joe!duck@opera.iinet.net.au PRIVMSG #~~chatx~~ :^APING 866780265^A</blockquote>	+	<blockquote>:Joe!duck@opera.iinet.net.au PRIVMSG #DareNET :^APING 866780265^A</blockquote>

	For example, a reply to this ping would be:		For example, a reply to this ping would be:

Admin: /* What are the common CTCP commands? */

Admin — Wed, 17 Oct 2007 00:42:08 GMT

What are the common CTCP commands?

← Older revision		Revision as of 00:42, 17 October 2007
Line 45:		Line 45:
	== What are the common CTCP commands? ==		== What are the common CTCP commands? ==

-	<pre>CLIENTINFO, ACTION, DCC, ERRMSG, FACE, FINGER, PING, SOUND, SOURCE, TIME, USERINFO, VERSION, and XDCC.</pre>	+	<pre>CLIENTINFO, ACTION, DCC, ERRMSG, FACE, FINGER, PING, SOUND, SOURCE, TIME, USERINFO, VERSION,
		+	and XDCC.</pre>

	Briefly, this is what each command does:		Briefly, this is what each command does:

Admin at 00:15, 12 August 2007

Admin — Sun, 12 Aug 2007 00:15:55 GMT

← Older revision		Revision as of 00:15, 12 August 2007
Line 138:		Line 138:
	CTCP commands and replies are in the format of ((privmsg/notice) ((target):^A((command) ((arguments)^A.		CTCP commands and replies are in the format of ((privmsg/notice) ((target):^A((command) ((arguments)^A.

-	[[Category:~~Documentation~~]]	+	[[Category:Technical]]

70.171.208.100: /* What can I do if I want more information on CTCP? */

70.171.208.100 — Fri, 03 Aug 2007 19:22:02 GMT

What can I do if I want more information on CTCP?

← Older revision		Revision as of 19:22, 3 August 2007
Line 129:		Line 129:

	*[http://www.irchelp.org/irchelp/rfc/ctcpspec.html CTCP Specification], written in 1994.		*[http://www.irchelp.org/irchelp/rfc/ctcpspec.html CTCP Specification], written in 1994.
-	*[http://www.invlogic.com/irc/ctcp.html Unofficial updated draft of the CTCP Spec], adopted by most major IRC ~~client~~ including mIRC.	+	*[http://www.invlogic.com/irc/ctcp.html Unofficial updated draft of the CTCP Spec], adopted by most major IRC clients including mIRC.
	*[http://en.wikipedia.org/wiki/Direct_Client-to-Client DCC Specification]		*[http://en.wikipedia.org/wiki/Direct_Client-to-Client DCC Specification]

70.171.208.100 at 19:21, 3 August 2007

70.171.208.100 — Fri, 03 Aug 2007 19:21:12 GMT

70.171.208.100: New page: == What does CTCP stand for? == CTCP stands for Client To Client Protocol. This is not to be confused with the CCCP ;) == Why is it called Client to Client Protocol? == Because it is se...

70.171.208.100 — Fri, 03 Aug 2007 19:19:42 GMT

New page: == What does CTCP stand for? == CTCP stands for Client To Client Protocol. This is not to be confused with the CCCP ;) == Why is it called Client to Client Protocol? == Because it is se...

New page

== What does CTCP stand for? ==

CTCP stands for Client To Client Protocol. This is not to be confused with the CCCP ;)

== Why is it called Client to Client Protocol? ==

Because it is sent and interpreted by your IRC client. The IRC server has nothing to do with CTCP. It treats a CTCP message as just another /msg to someone. Unlike other commands, for example /whois.

== How does CTCP work? ==

In CTCP, there are two forms of communication: COMMAND and REPLY. Commands are sent as follows:

<bockquote>PRIVMSG ((target):^A ((command>) ((value)^A</bockquote>

Where - ^A = ASCII Character 1 
- command = CTCP command 
- value = value to be processed by the target's client

And REPLIES in this format:

<bockquote>NOTICE ((target):^A ((command) ((value)^A</bockquote>

Where - ^A = ASCII Character 1 
- command = CTCP command 
- value = value to be processed by the target's client

For example, a ping of channel #chatx would be:

<bockquote>PRIVMSG #chatx :^APING 866780265^A</bockquote>

This message would be received by all the people on channel #chatx but yourself. They would all get this:

<bockquote>:Joe!duck@opera.iinet.net.au PRIVMSG #chatx :^APING 866780265^A</bockquote>

For example, a reply to this ping would be:

<blockquote>NOTICE Joe :^APING 866780265^A</blockquote>

This message would be received by Joe like this:

<bockquote>:Skinner!sjm076@ppp-per-217.ca.com.au NOTICE Joe :^APING 866780265^A</bockquote>

Joe's client would then interpret this as being a reply to a PING and process it accordingly, in this case, taking the timestamp (866780265) and subtracting it from the current timestamp.

== What are the common CTCP commands? ==

<pre>CLIENTINFO, ACTION, DCC, ERRMSG, FACE, FINGER, PING, SOUND, SOURCE, TIME, USERINFO, VERSION, and XDCC.</pre>

Briefly, this is what each command does:

'''CLIENTINFO''' -- Display valid CTCP commands for that client.

'''ACTION''' -- when you type /me does this, it is actually sent as a CTCP message. However, unlike other CTCP commands, it does not require a REPLY, and none should be given.

'''DCC''' -- DCC is established by CTCP, however it is not conducted over CTCP. See the section on DCC for more information on this protocol.

'''ERRMSG''' -- Reply to unknown CTCP command.

'''FACE''' -- Pictographic 32x32 pixel representation of user (Macintosh clients only)

'''FINGER''' -- Shows idletime of client, usually with an e-mail address and message.

'''PING''' -- Used to measure lag, or the time it takes for information to travel between servers.

'''SOUND''' -- Causes the client(s) that receive it to play a sound file.

'''SOURCE''' -- A URL where the client/script can be obtained.

'''TIME''' -- Local time of recipient.

'''USERINFO''' -- Shows a "witty" saying set by user.

'''VERSION''' -- Replies with IRC client version.

== Why don't some IRC clients support all these? ==

Because they don't basically ;) However, nearly every IRC client will support CLIENTINFO, which shows what commands that client supports.

== How do I send a CTCP command? ==

"/CTCP ((target) ((command)" is implemented in nearly every IRC client. For those that it isn't, usually commands like /version ((target), /ping ((target), etc., are. The exception to this is PING, which is usually done by /ping ((target) (or /cping ((target) in ircle).

It should be noted that /version is an ircd command as well.

== What is a CTCP flood? ==

It is when someone maliciously makes your client reply to CTCP messages with the purpose of making you disconnect from the IRC server.

== How do CTCP floods work? ==

Most servers are set up to allow you receive more data than you can send; therefore some commands such as CLIENTINFO can be used to disconnect you.

The command to make your client reply to a CLIENTINFO is 12 characters (plus source/target information), while the reply to CLIENTINFO may be 100 - 200 characters. You will be disconnected with the message "Excess Flood."

== What about DCC? =

DCC is started by a CTCP command. However, once it is started, it is conducted totally independant of the IRC server. For example, to start a DCC chat connection, the originator of the request (whoever typed /dcc chat ((nick)] will send something like this:

<bockquote>PRIVMSG ((target) :^ADCC CHAT ((type) ((longip) ((port)^A</bockquote>

^A = ASCII Character 1 
type = Either Chat or Talk, but almost always Chat these days 
longip = 32-bit Internet address of originator's machine 
port = Port on which the originator is waitng for a DCC chat 

The person I want to DCC chat would get this:

<bockquote>:Joe!duck@opera.iinet.net.au PRIVMSG SomeOne :^ADCC CHAT CHAT 3406736986 2094^A</bockquote>

From this, their IRC client would know that the machine with address 3406736986 is ready to accept a DCC chat connection on port 2094. The IRC client of the target of the DCC chat would then establish a connection to port 2094 of machine 3406736986 if the DCC chat was accepted.

DCC file sends are similar to DCC chat requests, but follow the format below:

<bockquote>PRIVMSG ((target) :^ADCC SEND ((filename) ((longip) ((port) ((filesize)^A</bockquote>

Where - ^A = ASCII Character 1 
- filename = Name of file being sent 
- longip = 32-bit Internet address of originator's machine 
- port = Port on which the originator is waiitng for a DCC chat 
- filesize = Size of file being sent 

The person I want to send a file to would get this:

<bockquote>:Joe!duck@opera.iinet.net.au PRIVMSG Someone :^ADCC SEND CTCP_and_DCC 3406736986 2097 4509^A</bockquote>

From this, their IRC client would know that the machine with address 3406736986 is ready to send a file named "CTCP_and_DCC" that is 4509 bytes long on port 2097. The IRC client of the target of the DCC send would then establish a connection to port 2097 of machine 3406736986 if the DCC send was accepted.

== What can I do if I want more information on CTCP? ==

*[http://www.irchelp.org/irchelp/rfc/ctcpspec.html CTCP Specification], written in 1994.
*[http://www.invlogic.com/irc/ctcp.html Unofficial updated draft of the CTCP Spec], adopted by most major IRC client including mIRC.
*[http://en.wikipedia.org/wiki/Direct_Client-to-Client DCC Specification]

== Summary ==

CTCP commands are sent as privmsgs. CTCP replies are sent as notices.

CTCP commands and replies are in the format of ((privmsg/notice) ((target):^A((command) ((arguments)^A.

[[Category:Documentation]]

← Older revision		Revision as of 19:21, 3 August 2007
Line 11:		Line 11:
	In CTCP, there are two forms of communication: COMMAND and REPLY. Commands are sent as follows:		In CTCP, there are two forms of communication: COMMAND and REPLY. Commands are sent as follows:

-	<~~bockquote~~>PRIVMSG ((target):^A ((command>) ((value)^A</~~bockquote~~>	+	<blockquote>PRIVMSG ((target):^A ((command>) ((value)^A</blockquote>

	Where - ^A = ASCII Character 1<br>		Where - ^A = ASCII Character 1<br>
Line 19:		Line 19:
	And REPLIES in this format:		And REPLIES in this format:

-	<~~bockquote~~>NOTICE ((target):^A ((command) ((value)^A</~~bockquote~~>	+	<blockquote>NOTICE ((target):^A ((command) ((value)^A</blockquote>

	Where - ^A = ASCII Character 1<br>		Where - ^A = ASCII Character 1<br>
Line 27:		Line 27:
	For example, a ping of channel #chatx would be:		For example, a ping of channel #chatx would be:

-	<~~bockquote~~>PRIVMSG #chatx :^APING 866780265^A</~~bockquote~~>	+	<blockquote>PRIVMSG #chatx :^APING 866780265^A</blockquote>

	This message would be received by all the people on channel #chatx but yourself. They would all get this:		This message would be received by all the people on channel #chatx but yourself. They would all get this:

-	<~~bockquote~~>:Joe!duck@opera.iinet.net.au PRIVMSG #chatx :^APING 866780265^A</~~bockquote~~>	+	<blockquote>:Joe!duck@opera.iinet.net.au PRIVMSG #chatx :^APING 866780265^A</blockquote>

	For example, a reply to this ping would be:		For example, a reply to this ping would be:
Line 39:		Line 39:
	This message would be received by Joe like this:		This message would be received by Joe like this:

-	<~~bockquote~~>:Skinner!sjm076@ppp-per-217.ca.com.au NOTICE Joe :^APING 866780265^A</~~bockquote~~>	+	<blockquote>:Skinner!sjm076@ppp-per-217.ca.com.au NOTICE Joe :^APING 866780265^A</blockquote>

	Joe's client would then interpret this as being a reply to a PING and process it accordingly, in this case, taking the timestamp (866780265) and subtracting it from the current timestamp.		Joe's client would then interpret this as being a reply to a PING and process it accordingly, in this case, taking the timestamp (866780265) and subtracting it from the current timestamp.
Line 93:		Line 93:
	The command to make your client reply to a CLIENTINFO is 12 characters (plus source/target information), while the reply to CLIENTINFO may be 100 - 200 characters. You will be disconnected with the message "Excess Flood."		The command to make your client reply to a CLIENTINFO is 12 characters (plus source/target information), while the reply to CLIENTINFO may be 100 - 200 characters. You will be disconnected with the message "Excess Flood."

-	== What about DCC? =	+	== What about DCC? ==

	DCC is started by a CTCP command. However, once it is started, it is conducted totally independant of the IRC server. For example, to start a DCC chat connection, the originator of the request (whoever typed /dcc chat ((nick)] will send something like this:		DCC is started by a CTCP command. However, once it is started, it is conducted totally independant of the IRC server. For example, to start a DCC chat connection, the originator of the request (whoever typed /dcc chat ((nick)] will send something like this:

-	<~~bockquote~~>PRIVMSG ((target) :^ADCC CHAT ((type) ((longip) ((port)^A</~~bockquote~~>	+	<blockquote>PRIVMSG ((target) :^ADCC CHAT ((type) ((longip) ((port)^A</blockquote>

	^A = ASCII Character 1<br>		^A = ASCII Character 1<br>
Line 106:		Line 106:
	The person I want to DCC chat would get this:		The person I want to DCC chat would get this:

-	<~~bockquote~~>:Joe!duck@opera.iinet.net.au PRIVMSG SomeOne :^ADCC CHAT CHAT 3406736986 2094^A</~~bockquote~~>	+	<blockquote>:Joe!duck@opera.iinet.net.au PRIVMSG SomeOne :^ADCC CHAT CHAT 3406736986 2094^A</blockquote>

	From this, their IRC client would know that the machine with address 3406736986 is ready to accept a DCC chat connection on port 2094. The IRC client of the target of the DCC chat would then establish a connection to port 2094 of machine 3406736986 if the DCC chat was accepted.		From this, their IRC client would know that the machine with address 3406736986 is ready to accept a DCC chat connection on port 2094. The IRC client of the target of the DCC chat would then establish a connection to port 2094 of machine 3406736986 if the DCC chat was accepted.
Line 112:		Line 112:
	DCC file sends are similar to DCC chat requests, but follow the format below:		DCC file sends are similar to DCC chat requests, but follow the format below:

-	<~~bockquote~~>PRIVMSG ((target) :^ADCC SEND ((filename) ((longip) ((port) ((filesize)^A</~~bockquote~~>	+	<blockquote>PRIVMSG ((target) :^ADCC SEND ((filename) ((longip) ((port) ((filesize)^A</blockquote>

	Where - ^A = ASCII Character 1<br>		Where - ^A = ASCII Character 1<br>
Line 122:		Line 122:
	The person I want to send a file to would get this:		The person I want to send a file to would get this:

-	<~~bockquote~~>:Joe!duck@opera.iinet.net.au PRIVMSG Someone :^ADCC SEND CTCP_and_DCC 3406736986 2097 4509^A</~~bockquote~~>	+	<blockquote>:Joe!duck@opera.iinet.net.au PRIVMSG Someone :^ADCC SEND CTCP_and_DCC 3406736986 2097 4509^A</blockquote>

	From this, their IRC client would know that the machine with address 3406736986 is ready to send a file named "CTCP_and_DCC" that is 4509 bytes long on port 2097. The IRC client of the target of the DCC send would then establish a connection to port 2097 of machine 3406736986 if the DCC send was accepted.		From this, their IRC client would know that the machine with address 3406736986 is ready to send a file named "CTCP_and_DCC" that is 4509 bytes long on port 2097. The IRC client of the target of the DCC send would then establish a connection to port 2097 of machine 3406736986 if the DCC send was accepted.