IRC Hacks [Electronic resources] نسخه متنی

Hack 78 Understanding the IRC Protocol

The IRC protocol is a text-based protocol.
Exploit it with just a little knowledge of its features and
restrictions.

Because the IRC
protocol is text based, you can easily look at it and see
what's going on. You can do this either by creating
a raw Telnet connection to an IRC server and typing the commands
manually or by running a packet sniffer that displays all of the
traffic going in and out of your IRC client.

Some IRC clients even let you see what's going on at
the protocol level. For example, in
mIRC,
you can type /debug @output to make a new
window that displays all raw lines being
sent to and from the IRC server. The output looks something like
Figure 13-1.

Figure 13-1. mIRC debug window showing the raw IRC messages

13.2.1 Asynchronous by Nature

The IRC protocol is
asynchronous, consisting of a series of events
about which you are notified. All these events come through on the
same connection, line by line regardless of their content; messages
from one channel are interleaved with those of another channel,
private messages, server notices, and more.

If you wish the server to send you a list of names on a channel, the
server will happily oblige. However, the data will be sent like any
other data. If you want to interpret the data and include it in, say,
a user list in the IRC client you're programming (or
perhaps a user list for a channel bot), you will need to set it up to
expect that data. The data must be received one line at a time and be
redirected to some sort of data structure that will hold it until the
list is complete.

You cannot simply request the list and expect that its content will
immediately follow. Some other data might come through first, or
there might be a channel message in the middle of the list. On a
related note, you should not wait forever for a replythere is
always the possibility that it will never come.

Furthermore, the IRC server will not confirm
your actions. If you send a message to a channel, you can only assume
that it made it to the channel. The IRC server will not send anything
in reply if it did. Therefore, if you're programming
some sort of IRC client, you can only assume that whatever you type
is going through and display it on screen. If you ask to join a
channel, you cannot assume that you have joined it until the server
tells you so. This asynchronous nature makes it possible for IRC
servers to force IRC clients to join a particular channel, as most
IRC clients will be unaware that they haven't
actually asked to join that channel.

On a related note, you should be prepared to expect the unexpected
from the IRC server. Although it doesn't generally
happen, by virtue of the IRC protocol, you could be sent username
lists, have your nickname changed without even asking for it, have
words put into your mouth, be summoned into random channels, and so
on.

As a general rule, you should always listen to the IRC server and
accept what it tells you. For example, some servers can be set up to
make you automatically join a channel when you connect, and your IRC
client must accept this, even if it knows it has never asked to join
that channel. Strange events like this rarely happen but become more
common when you try to share the same IRC connection among several
IRC clients at the same time. JBouncer (http://www.jibble.org/jbouncer) is an IRC
proxy that lets you resume proxy sessionseven if other clients
are already using themresulting in multiple replies when you
/VERSION the proxy user (see [Hack #85] ).

13.2.2 The Protocol

The IRC
protocol is defined in RFC 1459 and updated in RFC 2812. These are
both good references and explain the protocol in augmented BNF
format. If you don't know what that means,
you'll be glad to know a few examples of each
message type follow.

13.2.2.1 Message

Messages have the
following format:

prefix command command-parameters\r\n

The line must end with an


ASCII carriage return and linefeed
(\r\n). The line is not allowed to be more than
512 characters long, including the CR+LF at the end.

The prefix is optional and is generally used only
in incoming messages. If there is a prefix, the message will start
with a colon character (:).
It will contain either the name of an IRC server, an IRC nickname, or
an IRC nickname and
host mask
(nick!ident@host). This identifies the source of
the message; if there is no prefix, you should assume the message
came from your client.

The command is either one of the IRC text-based
commands or, in some incoming messages, a three-digit response code.

The
command-parameters are also optional. In many
commands, the parameters will consist of a destination and a message.
The message is prefixed with a : to separate it
from the rest of the command parameters.

13.2.2.2 PRIVMSG

The most common


command sent to an IRC server is
PRIVMSG. Although it might seem that this command
would be limited to private conversations between users, it is in
fact used to send messages to channels as well. Its format is:

prefix PRIVMSG destination :message-contents

For example, a message sent to a channel could end up looking like
this when it is received:

:Tracey`^!me@68.178.52.73 PRIVMSG #game1 :She's dead. Keep laughing.

A message sent to another user would look like this when he receives
it:

:AlcarGM!alcar@g42-70-262-54.ok.comcast.net PRIVMSG Brisby :And no, Tracey
doesn't know Oscar.

Of course, when you send a message, you can make things a bit simpler
by not having to specify your own host mask. So to send a message to
a channel, your client would simply have to send:

PRIVMSG #game1 :(( Keep laughing?!? YOU INSENSITIVE CLOD!!! ))

Likewise, to send a message to another user (in this case,
Gandalf[bot]), you could just do this:

PRIVMSG Gandalf[bot] :Note to Fennec: Where have you been?!?!?!

You can also send private messages by specifying the
fully qualified host mask for the user, for example:

PRIVMSG JacobRiis!~fennec@fennec.computer.wfu.edu :I know where you sleep!!!

Note also that there is no IRC command for an
action. These commands are handled by the CTCP
command ACTION , and are transported via
PRIVMSG commands, as shown in [Hack #85] .

13.2.2.3 NOTICE

A NOTICE
is much like a PRIVMSG, but RFC 2812 absolutely
forbids that any automated reply be sent to a
NOTICE. This restriction is designed to prevent
infinite loops between automatic systems such as IRC bots. The syntax
is the same as for PRIVMSG. The
NOTICE command is not used very often, although
you may see it coming from IRC service commands such as NickServ
[Hack #5] and ChanServ [Hack #9].

People may be upset if you send many NOTICE
messages to a channel because, depending on the nature of the IRC
client, NOTICE messages are seldom displayed or
interpreted as nicely as normal PRIVMSG commands.

13.2.2.4 PING/PONG

Every so

often, the server may check to see if
you're still connected. It does this by sending a
PING message. This message should be immediately
replied to with a PONG command with the same
parameters. Failure to do so could result in a ping
timeout, which will result in the server disconnecting
you.

Example:

PING 1079550066

Reply:

PONG 1079550066

Thomas Whaples