...under revision...
With a simple, clearly defined protocol, IRC has become
one of the most accessible chat environments, with clients
written for a multitude of operating systems.
Users of alternative chat systems will find IRC pretty easy to pick
up and may even be surprised to find that it is more powerful,
allowing not just chat between pairs of users, but among groups
of hundreds, even thousands. It is the scalable nature of IRC that
has helped it to succeed and to make it the most mature chat system
on this planet.
So...What's All About?
It's about communication.
IRC is yet another facet of the ongoing revolution in telecommunications called the
Internet.
IRC makes the most of it by offering something beyond the Web and email: the ability to communicate directly, interactively, and in real time mainly with group of persons or privately any single person if you wish to.
IRC is more than entertainment. It's active communication. You can tune into IRC and its diverse multitude of networks and channels and join an online society.
It's important to always remember that IRC consists of real people, with all the faults and advantages that implies.
When it comes to real-time communication over the Internet, you have several options: proprietary systems like the chat rooms on
America Online or
Prodigy that are available only to subscribed members, the likes of
Instant Messenger or ICQ, MSN, or local
bulletin boards, to name the most widely used means. Each has its advantages and disadvantages, and the choice is not always easy.
IRC is special in the way the simplicity of text chat expands to include the parallel transfer of files, which can be used for visual and auditory enhancement of an IRC session. Nowhere else in the world will you find so many opportunities to mingle with the other occupants of the global village.
IRC is where you can see the borders of nationality, race, and creed that confine us in everyday life crumble more readily than anywhere else. You could say it is global warming in its safest form.
Tech Concept
The keyword in IRC acronym is
Relay. IRC, in its simplest form, is made up of two programs—a server program that accepts connections from clients and a client program that connects to the server and ask stuff.
Of course, it isn't absolutely necessary to use a special program(IRC client)—the server would view a simple network connection between you and the server as a client. However, a dedicated IRC client program handles some necessary procedures automatically and provides a better and simpler user interface than the more technical messages the client and server exchange.
IRC servers connect to each other via an IRC network of servers. Let's use a very simple model of an IRC network for our example: two servers and two clients. The servers are connected to each other, and each has a client (a user) connected to it. The structure would look like this:
Let's say Jack wishes to send a message to Jill. However, their PC's don't connect directly but are connected indirectly trough two IRC servers A and B. Therefore, Jack can make use of the indirect route (Jack --> Server A -->Server A --> Jill ) that exists between him and Jill.
What Jack does is send
server A a message. In this message, he will tell
server A the message's final destination (Jill) and its contents.
Server A is aware of the existence of Jill, although she's not connected to it directly, and it knows that she's connected to
server B.
excerpt from Linux IRC mini−HOWTO
This distributed model, which requires each server to have a copy of the global state information, is still the most flagrant problem of the protocol as it is a serious handicap, which limits the maximum size a network can reach. If the existing networks have been able keep growing at an incredible pace, we must thank hardware manufacturers for giving us ever more powerful systems.
Server A therefore forwards—relays—the message to
server B, which in turn sees that the recipient is one of its own clients and sends the message to Jill, who can then read it.
Server A also adds the
identity of the client sending it (Jack) before relaying it, so the recipient knows who it's from. This transfer of information between the servers and its users typically happens within milliseconds, thus making the exchange of messages swift enough to match that of real conversation.
This is why(cause of servers) Jack doesn't need to connect directly to Jill to send his message—
the IRC environment permits an almost unlimited number of recipients for the same message and can relay this message to all those users at the same time. IRC permits one-on-one communication, but
its real advantage is the ability to communicate with large numbers of people by sharing a common channel of conversation.
Let's say we add a third user Joe (C in fig.) is connected to server B, just like Jill is. All three of them join a channel. They arrange the channel name by sending messages to each other. Establishing this channel gives them a means of
three-way communication(Person-channel-Person)
. So if Jill wants to tell Jack, something and sends the message to the channel instead of sending it only to Jack, all users on the channel receive the message.
Users and channels are the main components in the conceptual model of IRC. Users are the people you talk to, and you can also talk to channels, which contain groups of users. Channels are often built around a particular topic or theme, so is up to any IRC user finding the right channel to join.
Opinions on the pronunciation of IRC still vary. Some
prefer to pronounce it "irk," while others prefer calling it
"eye-are-see." Historical
documents dating back to the early days support the former, and it
matches the Finnish pronunciation.
Origin and History of IRC
A system based on a similar concept as IRC appeared on the U.S. military network much earlier, although it did not make its way to the broader community.
But IRC as it is now known evolved from a program Jarkko Oikarinen at Oulu University (Oulu is a small town on the north western coast of Finland) wrote in the summer of 1988 . Oikarinen added some extensions to a multiuser form of the classic
talk, a means of one-to-one live communication between Internet users, which had the drawback of not supporting
three-way or
group communication.
Of course, the original IRC was far simpler than modern versions, which have made IRC one of the most complex systems on the Internet. Although there is no longer an IRC server on Oikarinen's original machine, called the oulubox, there is still an IRC server at the original site serving local users.
Very early on, IRC was an entirely Finnish affair and largely geared towards Finnish users. Soon after its creation, IRC was exported, and servers in Oulu and Gothemburg, Sweden, made the first international connection, followed soon by Boston, Massachusetts, although the connections were not stable. In those days, the Internet was still a thing of the future, and many of today's main connections didn't exist at that time. Nor was all communication carried over dedicated lines, especially transcontinental and overseas.
"Internetworking" was more often than not subject to the limitations of the regular telephone network and its tariffs, making it a costly affair that even the fairly affluent educational institutes of northern Europe and the United States couldn't support easily.
Since then, IRC has spread all over the world, together with the Internet's development and as part of it. The number of regular and circumstantial (those who use it sporadically) IRC users is impossible to determine, but probably reaches well into seven digits. So far, people in over 120 countries and territories on all continents have used IRC, and it's arguably third only to email and the World Wide Web (WWW) in popularity.
IRC's first claims to fame and recognition came in early 1991, during the military operation to expel Iraq from Kuwait ("Desert Storm") as well as in September 1993, following the coup against President Yeltsin in Moscow, when local IRC users relayed reports of the situation around the world. As far as the general public was concerned, however, it was just "the Internet," and few commentators had the knowledge to describe the means used—that is, IRC. Such reports of local happenings have always been a part of IRC life, but rarely did they lead to publicity and even less often to reaching the public with serious information about IRC. Even in 2000, a number of experienced Internet users and an unbelievably large number of professional technical or support personnel working with the Internet have absolutely no knowledge of the workings or even the existence of IRC.
With time, the complexity of all aspects of IRC has increased greatly, making both maintaining and using it much more complicated and involving its users with a lot more technical details than most other Internet applications.
IRC started out in 1988 with only a handful of users, all of them also involved in developing the software and establishing the rules that now form the foundation of IRC.
With the number of educational institutions all over the world connecting to the Internet rising sharply in the early 1990s and, consequently, large numbers of students at those institutes gaining access, the number of regular users grew to reach a maximum of 5,000 simultaneous connections in 1992.
Politics made their appearance in the IRC community pretty soon, however, and it became apparent that not everyone shared the same vision of the future. Some decided to follow their own way, breaking up the first network of IRC servers into smaller ones, although few of these splintered networks survived for long. But the changes have made modern IRC even more complicated, since the existing networks follow a number of different standards instead of adhering to a common set of technical and administrative methods. Of course, they all still follow a basic protocol, which is the technical foundation of IRC, so you can expect to encounter few problems related to those differences in the beginning. Any problems you encounter at first are more likely to be entirely human in character and origin.
Following the fragmentation of the IRC world into a number of separate entities, the combined user count of these continued to grow at an extremely high rate, even compared to the overall number of Internet users, reaching 20,000 for the largest network in early 1996. With dial-up services becoming increasingly available to the public in more and more parts of the world, subscribers to commercial Internet service providers (ISPs) have been the major contributors to the increase in users and, particularly in the more technologically developed countries in Europe, North America, and around the Pacific, now outnumber academic users by far.
Current trends show that the rate of growth could be as much as 30 percent annually, maybe even more. On February 22, 1999, EFnet, the largest IRC network, reached the landmark number of 50,000 simultaneous connections. It was the opinion of many in 1992 that IRC had reached its limits with the 5,000 concurent users seen then. This number is still being revised upwards—it's now acknowledged that there's no telling how high it will go.
CONNECTING TO A SERVER
Depending on your client, there are different ways of setting the server or list of servers to which you intend to connect. Most clients let you set a default server to which your client automatically connects at start-up. Some also let you specify one or more alternative servers in case you fail to connect to the first. Let's not rush things, though. First of all, you'll need to choose a network, and from its available servers select the one most likely to suit you.
Selecting a Network and Server, and Connecting
Earlier, we saw how the IRC world became divided into many different entities, each with its own special character. This structure may be confusing, but it certainly adds variety.
In order to pick the most suitable network, ask yourself what you're expecting to find on IRC.
- If you want to hang around, explore a few channels, and meet many different people, one of the major networks is probably the best choice.
- If you'd rather not jump in the deep end and prefer to practice your IRC skills before venturing into the metropolitan jungle of the large nets, there are numerous smaller nets, with few but friendly users and operators who are willing to help newcomers.
- If your personal ethics require a controlled environment free of potentially offensive material, one of the smaller U.S.-based networks with strict policies is the ideal choice, often a suitable place for your kids as well.
If your first choice doesn't work out, there are always many more. Remember, quantity doesn't necessarily mean quality—even if you're on a network with 30,000 or 40,000 users, you'll rarely contact more than a few dozen people at a time.
Once you find a network, check its server list for the nearest server.
This step is not absolutely necessary, but it is probably a good idea. Many networks have a generic server address that takes you to a random(round robin) server— for example, DALnet has the irc.dal.net address for that purpose, Freenode instead has chat.freenode.net (or irc.freenode.net), and mIRC users know it as Random US DALnet server on their server list.
On an off-topic note, IRC is mainly a casual chat and recreational environment. You won't generally find serious professional topics such as medicine or law, for the very good reason that although IRC includes many professionals from many different fields, they prefer to frequent channels that focus on general chat or a hobby. After all, would you be want to end a day at work with a visit to IRC, only to devote it to an unpaid rerun of the day's work? I might give out some free advice if a topic related to my line of work comes up in a channel I'm on, but I don't sit and wait for "customers." If you need a professional opinion and can't find someone nearby,
Usenet (a collection of email-based
newsgroups) is a much better place to look. Besides, nothing prevents an unqualified person from posing as a professional. Following medical advice from someone on IRC who claims to be a doctor is risky at best.
While the technical part of client-server communication must be consistent (with slight variations, depending on the type of server), the user interface for selecting a server and connecting to it varies from client to client.
Whether you pick a description from a menu or enter a server name manually, you should be familiar with the way Internet addresses are built. This way you don't need a menu in order to make your way to a server.
Internet Addressing
Two or three parts compose the name of any machine on the Internet, using the following structure:
[arbitrary.hostname.]domain.tld
tld: is the
top level domain.
It can be a generic one like
com, mil, or
edu etc which implies the nature of the organization using it (that is, company, military, educational). Some of these can be registered and used by anyone, anywhere in the world.
In other cases it denotes a country—for example
fr for France or
mx for Mexico
gr for Greece etc. The country codes follow the
ISO 3166 standard . Some countries use their tld and an extra identifier for the type of organization. For example,
com.tr is a company in Turkey (country code
tr), and
ac.il is an educational (academic) facility in Israel (country code
il). Major tlds using this system include Australia (
au), Brazil(
br), the United Kingdom (
uk), Japan (
jp), and South Africa (
za).
To make things even more confusing, some countries use both systems. In Canada and the United States it is also possible to have a state or province code precede the country code—for example,
fl.us (Florida) or
mb.ca (Manitoba).
domain. : The other essential part is the
second level domain, which conies before the tld (
identifier.tld) combination. This is a name the site chooses which is registered with the competent authority. Examples are
netscape.com (home of Netscape Communications) and
demon.co.uk (Demon Internet, a major ISP in the United Kingdom).
arbitrary.hostaname. : Everything before the second level domain is a machine name—an arbitrary choice of the domain's maintainers.
- Some indicate the function of the machine to which they point: for example, "www" indicates a Web server and "ftp" indicates an FTP server.
- It's also quite common for a machine name to have a structure of its own, as in irc.cs.cmu.edu, where the person maintaining the domain adds "cs" to indicate that it is part of an internal subdivision(Computer Science). This particular example is the address of the IRC machine at the computer science (cs) department of Carnegie-Mellon (cmu.edu).
Many sites maintaining an IRC server follow the convention of using "irc" as the machine's name. Some typical examples are
irc.mindspring.com (an IRC server operated by Mindspring Enterprises),
irc.demon.co.uk (the IRC server of Demon Internet, a company in the United Kingdom), or
irc.funet.fi (the IRC server of the Finnish University Network).
Many IRC networks have a distinct domain name all their servers share regardless of location, and the machine names might reflect a server's location or the name of the organization running it, as in
lasvegas.nv.us.undernet.org (an Undernet server in Las Vegas, Nevada),
webbernet.mi.us.dal.net (a DALnet server at webbernet.net in Michigan), and
irc.eu.dal.net (any European DALnet server).
Things That Can Go Wrong
The process of connecting to an IRC server can yield a surprising number of different errors and corresponding error messages, which can be confusing if you're not familiar with the syntax.
K-Lined, or You Are Not Welcome ...
The notice "K-lined" means that your address matches an entry on the server's internal list(blacklist) of addresses not permitted to use it; the server disconnects you after detecting this fact.
In effect, you are banned from using that server.
Messages to that effect can take a variety of forms, but in all cases you will not be able to use the server.
The reason you get for being
K-lined is actually an arbitrary message set by a server operator or administrator sets; there may even be no reason at all.
K-lines are known as such because the part of the configuration file where the server stores these "kill lines" and checkes upon them with each user connection consists of lines beginning with K: (so the correct term is really
K: line). Not all server operators are kind enough to provide a reason, so it might return no more than a generic "Banned" or "You are not welcome" notice. Don't take it personally—yet. Read on.
The most common reason for being
K: lined is that the server's operators have observed misbehavior from users within a group of addresses (of which yours is one), and therefore have decided not to permit any user from that group to use the server. Naturally, if you have never used the server before, it is not your fault, nor is anyone holding you personally responsible for some misconduct.
In many cases it affects a specific part of your ISP's addresses or even the entire ISP, and one obnoxious user sharing the same ISP may be causing the problem. This is a disadvantage of using a dynamic address.
Another reason for a K: line could be that you are expected to use a server closer to you in terms of either network topology or geographical location. K: lines aren't the preferred way of keeping non-local users out, but some server administrators use them for that purpose.
It doesn't make much sense for, say, a Swedish user to use a server in the United States if there are local servers available in Sweden, and vice versa.
In more severe cases, you may get
G-lined. Some IRC networks that have a global abuse policy implement
G: lines (are networkwide
K: lines also called
global K: lines).
On these networks, repeated or extensive abuse from a site may result in simultaneous K: lining from all servers on that network.
On
DALnet and other networks that use their server software, the equivalent of a
G: line is the
akill. The effect is the same.
Removing
K: lines is entirely at the discretion of the server's administrator. Many servers don't take too much care to remove old
K: lines, so they may remain in place indefinitely, even for years.
G: lines tend to have a set expiration date, which can be anywhere from 20 minutes to a month after it was set, depending on the severity of complaints against the
G: lined site or user. Some modern server versions use
temporary K: lines (automatically removed after a short while).
Unless you're having a really serious problem finding a server, simply remove the server from your list and connect to a different one. Alternatively, you may ask one of the server's operators or email the server's admin address to have it lifted —that is, if they are inclined to do so.
Ping Timeout
Ping timeouts are a common problem on slow connections. Perhaps you connect to the server successfully, but after the initial connection, nothing happens, and the connection closes after a minute or two with the message "Ping timeout":
09:50 -!- PunkOdissey[Out] [punkodisse@komodo.contextshift.eu] has quit [Ping timeout: 240 seconds]
This means the server got no reply from your client from the first PING. The server must receive a PONG reply to confirm that your client is connected and responding.
The cause for Ping timeout may be:
- a slow network connection or
- a heavy load on the server machine or your own,
either delaying the PING on its way to you or preventing the reply from reaching the server in the time it should.Network problems are by far the more common cause. Less common is a problem between certain servers and clients. This used to be a major nuisance, but now—although it hasn't entirely been fixed—newer versions of those particular servers send a message telling you to send a response manually if you are having trouble with Ping timeouts.
If the problem is on the server side, try connecting to a different server. You really shouldn't encounter such problems when using nowadays clients.
If you're having problems connecting to all servers, there's probably something wrong with your machine's or your site's network connectivity.
If you're positive the connection to your provider is fine and nothing needs fixing, then your provider's network connectivity is the most likely cause. You can use a network diagnostic utility named
traceroute to check the network path between yourself and the address you 're trying to connect to. Here's how:
$ traceroute < a d d r e s s >
IN WINDOWS
Click Start and open an MS-DOS(command.com) window. Enter the following:
C:\> tracert < a d d r e s s >
No More Connections/Server Full
This message is not unusual, especially during peak hours.
It means the number of connections the server has allotted to your connection class is full.
Few servers have a setup that groups all users under a single class. Instead, they define address groups with a maximum limit of users from each group who may be connected simultaneously—for example, by assigning all foreign addresses class 20 and setting a limit of 50 connections for class 20 in the configuration file. In this case, once the quota of 50 users is exhausted, the server rejects all foreign users attempting to connect, with a "Server full" or "No more connections" message, until at least one client of that class disconnects and frees the spot for another.
Another common reason for this message is that you were previously connected to the same server and lost your connection to it, but the server hasn't noticed it yet.
If the server permits a maximum of one client from any particular address, as many servers do, it detects your attempt to reconnect as a duplicate connection from an address that's already connected.
You can either use another server or wait for the previous connection to timeout on the server's side.
Connection Refused
The only cause for the "Connection refused" message is that no IRC server was listening for connections on the machine and/or port you tried to connect to.
Make sure the server name and the port number are correct and try again. If it continues to return the same message and you're positive about the server's host name and port, its IRC server or machine is having a problem.
Connect to a different server—there's no telling how long the server will be down.
Unable to Resolve Server Name
This indicates the failure of a
name server to convert the canonical name of the server like
irc.server.com, into an IP address such as 256.10.2.78.
This conversion is necessary for making any network connection.
Canonical names are more for human convenience—networked computers (and computers in general) only understand numbers and need them in order to make a connection. Those numbers eventually change into a string of 0s and 1s. Suffice it to say that your computer is turning everything you tell it into numbers and converting other numbers back into visual signals you can understand.
Failure to resolve server names may stem from a number of different causes. The most common is that either your local
name server or the one on which the server's address resides are out of order.
Your client sends your query to your local name server, which in turn looks up the name server that holds the records of the server's site (server.com) and then queries it for the IP address matching the canonical name you have given it (irc.server.com).
Naturally, your client handles the request and response internally, so you don't notice it—unless it fails. If this happens with all servers, it's definitely your local name server that has a problem. Your ISP's technical staff will fix it, but may not have noticed it. If your ISP is unreachable or can't fix it for a while, your options are either to use an off-site name server(like
openDNS), which requires you to know a name server's IP address(for openDNS Primary address:208.67.222.222, Secondary address: 208.67.220.220), or to find an IP address from an existing list of them.
PPP users would also have the added problem of having to change the settings of their
TCP/IP stack or use a separate lookup program. Therefore,
the easier solution is to find the IP addresses of the IRC servers you use most and add them to your list separately.
Note that IP addresses are liable to change without notice (for example, the administrator running the server may decide to use a different machine, or the route through which it connects to the rest of the Internet may change), so it's better to use the canonical names.
In the case of IRC networks that use a generic domain name for all their servers (
undernet.org, for example is a generic domain name for all Undernet servers), if the name servers serving
undernet.org are down, it will be impossible to resolve any of the network's servers.
The solution is to use an IP address or regular host name that you know corresponds to such a server. If you don't know any, try asking on one of the other networks' help channel, or try the network's website if there is one.
Illegal Nickname
The server sends this message if you select a nickname that's already in use or if the nickname you chose contains an unacceptable character.
Valid characters for nicknames include:
- a to z, A to Z, 0 to 9,
- and the following special characters: back slash (\), backstroke, or backtip (`), caret ( ^ ), dash (-), pipe (I), underscore (_), left square bracket ( [ ), right square bracket ( ] ), left curly bracket ({), and right curly bracket (}).
- The leading character cannot be a number or dash
Because IRC originated in Scandinavia, many servers consider the following pairs of special characters to be the same due to the layout of Scandinavian keyboards: left square bracket (]) and left curly bracket (}); right square bracket ([) and right curly bracket ({); and pipe ( I ) and backslash (\). These characters correspond to lowercase and uppercase letters on a Scandinavian keyboard. Because
IRC is not case-sensitive, each pair is regarded as being the same character.
If the nickname is valid and someone else is using your first choice, you can set most clients to fall back automatically to an alternative nickname:
08:48 -!- Mode change [+Zi] for user harryirssi
08:48 frigg [~frigg@freenode/utility-bot/frigg] requested CTCP VERSION from harryirssi:
08:48 -!- Irssi: Your nick is owned by http://harrykar.blogspot.com/ [~harrykar@unaffiliated/harrykar]
If this also fails or your client has no such feature, the server prompts you to enter a new nickname manually before it will accept you.
If you don't enter a new nickname soon enough, the server disconnects you with a Ping timeout.
This problem can present itself to users trying to connect to servers or networks running
Quarterdeck's IRC server software. Part of this software's non-standard behavior includes rejecting nicknames that would be quite legitimate on other servers, such as those with an underscore in them. If you can find nothing else wrong with your nickname, try using one made up entirely of letters.
Nickname or Channel Temporarily Unavailable
This message will only show up on servers running
IRCnet's server software. In this case, the nickname was recently in use by someone who didn't sign off "normally"
as seen from your server. A protective mechanism unique to this type of server prevents use of the nickname for approximately 15 minutes after the user's sign off. You will need to select a new nickname with the NICK command before the server accepts you. You may change back to the original one after the nick delay expires and the nickname becomes available again.
Ending Up on a Different Server
This is not a common problem—in fact, it often isn't a problem at all and may well go unnoticed. If a server is taken down permanently or temporarily, in order to spare the server's regular users the trouble of looking for another server, its administration may choose to redirect people trying to connect to it to a different server.
It can be a problem if the server you end up connecting to refuses you with one of the errors mentioned here because of a difference in configuration, or if the server you get redirected to is not on the same network as the one you originally connected to.
An example of the latter is what happened to users of America Online's IRC servers. AOL used to maintain servers on all four major networks. In November 1998, it was forced to remove its
EFnet server from that network. It then proceeded to take down the servers on
IRCnet and
DALnet of its own accord, leaving only its
Undernet server up. As if this weren't enough of an inconvenience to users, AOL also redirected the addresses of its former EFnet, DALnet and IRCnet servers to point to the remaining Undernet server, so everyone trying to connect to any AOL server would end up on Undernet whether they liked it or not. Needless to say, the company made no friends in doing this.
No Authorization
You can expect this message to appear when you're trying to connect to a foreign server.
Also, many servers accept few or no users from outside their domain, and attempts to connect return the error.
If this happens to you while you're trying to connect to a server you normally can access, the most likely explanation is name server failure. The server attempts to convert the IP address from which it detects your connection into a canonical host name, using the same procedure described earlier for lookup of the server's IP address. The difference is that it's requesting the reverse of what you asked for—IP to name instead of name to IP.
Apart from regular DNS problems, some ISPs have simply omitted or neglected adding reverse records for their addresses, not considering it essential to smooth operation. But unlike the case on most Internet connections, on IRC this practice can and will cause problems.
Many servers, on the large networks in particular, refuse to accept users whose IP address will not resolve to a canonical host name.
If you can confirm this as the problem, ask your ISP to see to it that
reverse DNS is enabled.
As long as you have this problem, you'll have fewer servers available.
Ident Required/Install Identd/Bad User name
Depending on your local machine, you'll either encounter these messages frequently or very rarely. A number of servers, especially on the major networks, require the presence of an ident server on the machine from which the client connection originates—in short, yours. "Install
identd" often appears as a
K: line reason, too.
If your client is running on your own machine, as is the case with PPP dial-ups, DSL's, the IRC server looks for this server(
identd) on your machine. Naturally, few users go to the trouble of installing a separate
identd on their machine.
The IRC clients usually cover this by emulating it and listening for ident requests in order to send the appropriate response. This is the case with Windows and Macintosh clients.
Ident queries go to port 113 of a machine. Your IRC client, if it's capable of emulating an ident server, listens for incoming queries on this port and, if you have it set up correctly, also send a valid reply, after which the server considers you "idented." Not all servers have rigid rules regarding ident, but it's a good thing to have in place. Developments on EFnet in particular have reduced the number of servers providing access for unidented hosts.
The response sent must match your declared user name, and the ident type should be set to UNIX.
This may not be true—for example, in the case of a Windows machine—but tell the server what it wants to hear anyway.
If the user name does not match the one you have told your identd to send, the server considers your ident response invalid, unidents you, and naturally refuses you if the server won't accept unidented users.
mIRC has port 113 and UNIX set by default under File > Setup Identd.
All you have to add is the user ID. If you don't add it, it will be taken from the email address.
Your user name and matching ident response can be practically any arbitrary string of up to 10 characters.
An important issue comes into play here, to which you should give thought. Of course, on a machine you yourself run and maintain, you can set your user name to be anything you like and hide your real log-in name, but even if you do,
bear in mind that total anonymity is an illusion. Either directly or with the cooperation of your ISP, your identity can be found.
By the way, user names such as "me," "ask," or "guess" are considered stupid since they're obviously both fake and unimaginative. Your credibility also suffers from silly fake user names or mixed upper- and lowercase user names. Some servers reject user names like that altogether. If you aren't the supervisor of the machine running your client, the system administrator must install the identd.
If there is no identd and the sysadmin is not willing to install one, that will definitely reduce the number of servers you may use, especially on the larger networks.
On a commercial ISP, it indicates a lack of interest in customers' needs.
Installing an identd isn't such a big deal and doesn't consume untold of hours of working time. In fact, it's a rather trivial task, and you shouldn't accept any excuses for the ISP's failure to do it. If the machine belongs to an educational or government site and the people responsible for the machine don't want to install it, fine. You can't force them to.
A special case of identd problem involves machines behind a firewall or using a proxy. Because you appear to be connecting from another machine, any identd you run on yours goes unnoticed.
Unless the firewall or proxy administrator pulls a few nifty tricks with the configuration, clients from these machines will not be able to ident. This is tricky business—it makes the firewall less effective, and you can't really expect any firewall administrator to bother with it.
Welcome to the Internet Relay
If all goes well, you make a successful connection to an IRC server. The lines you see in your client look something like this:
13:25 -!- Irssi: Looking up calvino.freenode.net
13:25 -!- Irssi: SASL: auth loaded from /home/harrykar/.irssi/sasl.auth
13:25 >> scriptassist 2003020803 loaded: /scriptassist help for help
13:25 -!- Irssi: Connecting to calvino.freenode.net [213.92.8.4] port 7000
13:25 -!- Irssi: Connection to calvino.freenode.net established
13:25 !calvino.freenode.net *** Looking up your hostname...
13:25 !calvino.freenode.net *** Checking Ident
13:25 !calvino.freenode.net *** Found your hostname
13:25 !calvino.freenode.net *** No Ident response
13:25 -!- Irssi: CLICAP: supported by server: identify-msg multi-prefix sasl
13:25 -!- Irssi: CLICAP: requesting: multi-prefix sasl
13:25 -!- Irssi: CLICAP: now enabled: multi-prefix sasl
13:25 -!- harrykar!harrykar@unaffiliated/harrykar harrykar You are now logged in as harrykar.
13:25 -!- Irssi: SASL authentication successful
13:25 -!- Welcome to the freenode Internet Relay Chat Network harrykar
13:25 -!- Your host is calvino.freenode.net[213.92.8.4/7000], running version ircd-seven-1.0.3
13:25 -!- This server was created Wed Feb 24 2010 at 00:02:02 CET
13:25 -!- calvino.freenode.net ircd-seven-1.0.3 DOQRSZaghilopswz CFILMPQbcefgijklmnopqrstvz bkloveqjfI
13:25 -!- CHANTYPES=# EXCEPTS INVEX CHANMODES=eIbq,k,flj,CFLMPQcgimnprstz CHANLIMIT=#:120 PREFIX=(ov)@+
MAXLIST=bqeI:100 MODES=4 NETWORK=freenode KNOCK STATUSMSG=@+ CALLERID=g are supported by this server
13:25 -!- SAFELIST ELIST=U CASEMAPPING=rfc1459 CHARSET=ascii NICKLEN=16 CHANNELLEN=50 TOPICLEN=390 ETRACE
CPRIVMSG CNOTICE DEAF=D MONITOR=100 are supported by this server
13:25 -!- FNC TARGMAX=NAMES:1,LIST:1,KICK:1,WHOIS:1,PRIVMSG:4,NOTICE:4,ACCEPT:,MONITOR: EXTBAN=$,arx WHOX
CLIENTVER=3.0 are supported by this server
13:25 -!- There are 364 users and 59249 invisible on 26 servers
13:25 -!- 34 IRC Operators online
13:25 -!- 9 unknown connection(s)
13:25 -!- 37000 channels formed
13:25 -!- I have 4942 clients and 1 servers
13:25 -!- 4942 5640 Current local users 4942, max 5640
13:25 -!- 59613 70487 Current global users 59613, max 70487
13:25 -!- Highest connection count: 5641 (5640 clients) (177201 connections received)
we should look at each line individually:
13:25 -!- harrykar!harrykar@unaffiliated/harrykar harrykar You are now logged in as harrykar.
This line means that the server has accepted your connection, and you're now known by the
nickname(before "!" character in user mask) of "harrykar" It also recognizes you as coming from the host named "unaffiliated" (normally "my.provider.com") and this host confirms that your
user name(after "!" character) is "harrykar"(casually here nicknme is the same as username)
Depending on the type of server, it may give your full user mask or just the nickname. Servers running customized software may replace "Internet Relay Network" with the network's name.
13:25 -!- Your host is calvino.freenode.net[213.92.8.4/7000], running version ircd-seven-1.0.3
The first part is obviously the server's name, but the second part is the server's 'Version" and identifies the type of server. In this example it stands for the ircd-seven-1.0.3 basic server version. ---This server can also running a patch (an add-on or bug fix) to add some features to the server that aren't part of the basic 1.0.3 code and that the administrator wishes to have. This is indicated by a plus sign(+) or slash mark(/), followed by the patch's identifier, and is present on a lot of networks' servers. It is often a server requirement.
13:25 -!- This server was created Wed Feb 24 2010 at 00:02:02 CET
This doesn't mean the server has existed only since that date and time, but says
when the current version of the server software was installed on the machine.
13:25 -!- CHANTYPES=# EXCEPTS INVEX CHANMODES=eIbq,k,flj,CFLMPQcgimnprstz CHANLIMIT=#:120 PREFIX=(ov)@+
MAXLIST=bqeI:100 MODES=4 NETWORK=freenode KNOCK STATUSMSG=@+ CALLERID=g are supported by this server
Oh gosh, more cryptic messages. These two strings indicate the settings (modes) available for users, also known as
umodes and
channel modes and characterized by certain letters. These strings differ depending on the type of server—for example,
umode r and
channel modes a and q are particular to an IRCnet server such as irc.webbernet.net, and the rest are present on all but the most divergent types of servers.
The server sends the next four to seven lines to the connecting client, but you can also request them at any time with the LUSERS command. They inform you of the network's and server's current status. The total number of users on the network is the sum of visible and invisible users.
Unknown connections are nothing more than incoming connections the server hasn't yet accepted and classified.
The final two lines are not standard, but many server administrators like to make that information visible.
13:25 -!- There are 364 users and 59249 invisible on 26 servers
13:25 -!- 34 IRC Operators online
13:25 -!- 9 unknown connection(s)
13:25 -!- 37000 channels formed
13:25 -!- I have 4942 clients and 1 servers
13:25 -!- 4942 5640 Current local users 4942, max 5640
13:25 -!- 59613 70487 Current global users 59613, max 70487
13:25 -!- Highest connection count: 5641 (5640 clients) (177201 connections received)
The Message of the Day
At the end of all this information you'll find the all-important MOTD—the server's Message of the Day. This text file, stored on the server machine and sent to all successfully connecting clients, describes the server's rules and policies, and sometimes contains useful information and announcements.
Despite its name, it's rarely a message "of the day and will sometimes be months old, depending on how satisfied with its contents the server's administrator is.
The amount and nature of the information it contains varies according to how conscientious that administrator is about informing the users of what they should know and of developments in the IRC world.
* - irc.acc.umu.se Message of the Day -
* - 13/4/2015 22:30
* - Welcome to irc.acc.umu.se!
* -
* - ==( Server Information )==========================================
* -
* - This server is running at Academic Computer Club, Umeå University
* - http://www.acc.umu.se/
* -
* - Your local admins: stric, maswan, av
* -
* - This server is also part of the GIMPNet network, also
* - known as irc.gnome.org. As such you should respect the
* - GNOME's Code of Conduct while participating in discussions
* - on any of the GNOME-related channels:
* -
* - https://wiki.gnome.org/Foundation/CodeOfConduct
* -
* - A list of the most relevant GNOME channels and other general
* - information can be found at the following page:
* -
* - https://wiki.gnome.org/Community/GettingInTouch/IRC
* -
* - The Network now supports nickname and channel registrations,
* - query NickServ, ChanServ (and issue the command 'help'), respectively.
* End of /MOTD command.
Although you'll soon become expert enough to get into the habit of ignoring it (I won't throw any stones here—when I started out, it didn't take me long to find out how to make it disappear), you should read it at least the first time you connect to a particular server.
Both
ircll and
mIRC provide a setting that suppresses display of the MOTD—this is convenient if you want less noise when connecting, but even a server you regularly connect to offers new and important information once in a while, so you're better off reading it regularly.
The MOTD is often much longer than your screen or window. If your client has a scrollbar in the window, back up to read the part you missed. With
ircll and similar clients, do the following:
/set holdjnode on
/motd
/set hold mode off
Your Identity on IRC
While you're connected, other users know you in two different ways. The first is simply your
nickname, which people need in order to reach you and see you on IRC. It's used as a destination address for messages and an identifier for server queries regarding you.
The second way is more complex and consists of three parts.
- The first part is your nickname. This is followed by an exclamation mark (!), which serves as a separator between it and the
- next field, which is your user name. Another separator, an at (@) character, follows.
- The last part is your host name or the IP address you're connecting from. (As I said previously, host names and IP addresses are equivalent for connecting, but the server treats them as text strings, and therefore they're considered different).
The final result looks like this:
SomeNick!george@my.provider.com
Nickname!username@host.name
This is your identity for sending to the server. Every item the server receives from your connection automatically gets this added to it as the sender's identity. If you send a message destined for a user or another server, this full version will be forwarded to the recipient along with the message. This is your
user mask on IRC.
Nickname Registration and Ownership
If the network you connected to has a
nickname service, you'll be able to reserve a nickname for your own use. Depending on the service's features, you may also be allowed to forbid others to use it in your absence or add personal information to your registration for others to see. The usual nickname for this type of service is
NickServ, and you can request help on how to use it by sending it a message:
/msg nickserv help08:00 -NickServ(NickServ@services.)- ***** NickServ Help ****
08:00 -NickServ(NickServ@services.)- NickServ allows users to 'register' a nickname, and stop
08:00 -NickServ(NickServ@services.)- others from using that nick. NickServ allows the owner of a
08:00 -NickServ(NickServ@services.)- nickname to disconnect a user from the network that is using
08:00 -NickServ(NickServ@services.)- their nickname.
08:00 -NickServ(NickServ@services.)-
08:00 -NickServ(NickServ@services.)- For more information on a command, type:
08:00 -NickServ(NickServ@services.)- /msg NickServ help
08:00 -NickServ(NickServ@services.)- For a verbose listing of all commands, type:
08:00 -NickServ(NickServ@services.)- /msg NickServ help commands
08:00 -NickServ(NickServ@services.)-
08:00 -NickServ(NickServ@services.)- The following commands are available:
08:00 -NickServ(NickServ@services.)- GHOST Reclaims use of a nickname.
08:00 -NickServ(NickServ@services.)- GROUP Adds a nickname to your account.
08:00 -NickServ(NickServ@services.)- UNGROUP Removes a nickname from your account.
08:00 -NickServ(NickServ@services.)- IDENTIFY Identifies to services for a nickname.
08:00 -NickServ(NickServ@services.)- INFO Displays information on registrations.
08:00 -NickServ(NickServ@services.)- LISTCHANS Lists channels that you have access to.
08:00 -NickServ(NickServ@services.)- REGISTER Registers a nickname.
08:00 -NickServ(NickServ@services.)- SET Sets various control flags.
08:00 -NickServ(NickServ@services.)- RELEASE Releases a services enforcer.
08:00 -NickServ(NickServ@services.)-
08:00 -NickServ(NickServ@services.)- Other commands: ACCESS, DROP, HELP, LISTOWNMAIL, LOGOUT,
08:00 -NickServ(NickServ@services.)- SETPASS, ACC, STATUS, TAXONOMY, VERIFY,
08:00 -NickServ(NickServ@services.)- VACATION
08:00 -NickServ(NickServ@services.)- ***** End of Help *****
Just as you may have exclusive use of a nickname by registering it with a nickname service, you may try to use a nickname already registered to someone else. If the nickname's owner has instructed the server to forbid its use by others, the server sends you a notice immediately after you connect or change to that nickname. This notice says that the nickname is reserved and you must either change it or the service will disconnect (kill) you for unauthorized use of a registered nickname or change your nickname to something else. It usually allows no more than a minute(30'' in Freenode) for you to change nicknames.
If you receive a notice saying something like that on a network you know has no nickname service, ignore it—someone is trying to make you release the nickname so they can use it.
As of April 1999, DALnet no longer allows use of NickServ in this manner. Messages must be directed to nickserv@services.dal.net.
The Realname Field
Part of your identity will be your
realname(alias ircname). This did originally contain a user's real name, but nowadays is used more often for displaying a witty comment or the location of a user's Web page. The text in the realname field is quite arbitrary. If you're using a client on your own machine, such as mIRC, Xchat etc, you can easily set the text you want to display by adding it to your client's setup.
Of course, there's nothing wrong with using your actual name, it's simply common to put something different in the space reserved for it.
If you're using a Unix system, setting the realname isn't that simple, and you'll probably have to go through the procedure of setting the IRCNAME
environment variable, which you should already have mastered while setting up your client.
User Modes (Umodes)
All servers permit a user to use
certain settings that influence the status of the session. The number and function of these settings varies greatly among different server types, so we'll limit ourselves to looking only at those that are present on most servers or are most important. Setting or removing a user mode for yourself is simple:
/mode +/-
Using the plus (+) before the letter corresponding to the user mode activates it, while the dash (-) unsets it. Omitting a prefix is the same as using a plus sign. User mode letters are case sensitive—W is not the same as w and may have a quite different effect or may not have a meaning at all.
Umode i
This is the most widely used user mode. User mode i (invisible), when set, makes a client invisible to certain types of user listings and scans. It's used for more privacy and to avoid harassment. This is also the solution to the problem of being targeted by spam bots.
Many servers automatically set it for a user upon connecting, in which case you'll see a notice that looks somewhat like this:
13:25 -!- Mode change [+Zi] for user harrykar
You can also set it manually:
/mode SomeNick +i
Use -i if you do not agree with it and the server has set it automatically, or if you no longer wish to be invisible. Some modern clients, including mIRC, Xchat etc, allow you to set umode +i automatically upon connecting, even if the server doesn't do so.
To set yourself as invisible automatically after connecting, whether the server does so or not, follow these steps:
Go to File > Options > IRC Servers and check the Invisible Mode box. Add a command to your .ircrcfile
MODE $N +i
Umode w
This lets you receive wallops, which are a special type of message servers or IRC operators send out, usually announcing some network event.
Only IRC operators need to see them, so you might as well leave it off. On some networks, only IRC operators can receive them, and user mode +w does nothing for the regular user.
Umode s
Umode s is the perfect way of getting your screen flooded with countless useless server notices. Umode s sends you all sorts of server notices, and there are often additional umodes that allow someone to monitor only a certain type of notice. Trust me—you don't need it.
Umode o
This user mode indicates that IRC operator status is active—therefore it's available only to IRC operators.
Trying to set umode +o is useless, since it's not obtained with a mode change, but with the OPER command, which only authorized users can use.
Umode d
Service robots often use umode d (dumb), which is not available on all server types.
On those networks that do allow users to use it, it prevents channel text from reaching the client and so is not very useful.
Umode r(restricted)
Umode r is unique to IRCnet servers and others with the same server software, but unlike other umodes specific to one type of server, this one can be annoying.
The server automatically sets it when a user connects; it indicates that the server will allow you to use it as a server, but doesn't give you access to the full, regular command set. The r stands for restricted. This restriction lies in the fact that you may not change your nickname without disconnecting from the server, and may not use channel operator commands, even if you are given channel operator status.
Perhaps neither of these interests you yet, but it's good to know this, since you could run into this problem later on.
The solution is usually to use a server that is closer to you geographically. If you already are, use the WHOIS command to check whether your host name is resolving—some servers impose the restriction on unresolved hosts instead of forbidding them to use the server.
Other Umodes
A variety of other modes exist that IRC operators use for monitoring the server. None of these are of any interest to the average user, so you'll do fine without them. Some umodes might be in use on different types of servers, but function differently—i, o, s, and w are the only ones you can expect will do the same thing on almost all servers.
The most interesting mode available on several small networks is known as x, a, or z depending on the network. The server can automatically set it, just like user mode i, and it hides the first part of your host name by replacing it with some other text. In effect, it fakes a user's host name and thus provides effective protection against DoS attacks, for which the attacker needs to know the target's address. If your small network server automatically sets a mode other than +i for you, this is probably it.
Changing Servers: The SERVER Command
Once you're connected to a server, you don't have to keep using the same one for your entire IRC session. If for any reason you want to use a different server, all good clients support the SERVER command, which lets you change servers without having to quit and restart your client. Its use is simple:
/server irc.otherserver.net
You can also specify a port on the new server other than the default by appending the port number:
/server irc.otherserver.net 6665
Though typing the command is really simpler, Gui irc clients users can also disconnect first with the connect-disconnect button (leftmost on the toolbar for Mirc) and then select a new server from the list.
Depending on the client you're using, one of two things may happen: Either your client closes the connection to the current server and initiates the new one, or it holds the old connection until the new one is established. This concerns only the TCP (network) connection—once this has been established, the old connection closes, even if the new server denies you access.
If you're using ircll, you can select a server from the internal server list. This is how it works:
- Each server you try to connect to gets added to this list with a number; you can view the list by typing /server. Then you can use the corresponding number instead of the server's name. You can also add the system's default servers to the internal list by using the -a switch from the command line when starting the client.
During your attempt to connect to the new server, you are liable to encounter any of the problems described earlier.
Using older versions of ircll, there is one more you may have to deal with. When you connect to a new server, the connection may just hang, leaving the cursor stuck in the top part of the window. After a while you get a message that the connection has failed and you return to the previous one, but your first connection has timed out while the cursor was stuck. More recent versions of ircll have corrected this problem, but the older versions are still widely used. It affects all versions up to 2.8.2. These versions allow the connections to block the client until the return of a conclusive response (failure or success). Blocking also means that the client, apart from not responding to your key presses, won't send PONGs in response to the current server's PINGs and the server is very likely to drop it with a ping timeout and lose the connection whether client establishes a new one or not.
Connect to more servers concurrently
To connect to a server without disconnect from others you are currently connected to as cmd /SERVER do, you need to type:
/connect server
For example, to get at the
quakenet irc network:
/connect irc.quakenet.org
and for
darkmyst the address is:
/connect irc.darkmyst.org
Disconnecting from a Server
At any time, you may close your connection to the IRC server. This is done via the QUIT command. Depending on the client you're using, there may be one or more synonyms for that command—for example, BYE, EXIT,LEAVE or SIGNOFF. In fact, some clients use one of these options rather than QUIT.
/quit
Closing the status window in a graphical client usually does the same, but doesn't confirm that the server has also closed the connection from its side. QUIT sends a QUIT command to the server and thus makes a clean disconnect by letting the server know you're leaving—otherwise it might take a while to notice that your connection is dead. Using QUIT or one of its synonyms, you simultaneously close your client application.
A message with arbitrary content may follow QUIT (and other commands with the same effect). If you add no message, it either sends none or defaults to a simple message like "Leaving." Your QUIT, plus the message (signoff reason) is sent to all channels you are on at that time.
You do not need to leave a channel before leaving IRC.
The server's operators may monitor QUITs (and the messages) on most networks. The messages are limited to a certain length, normally about 70 characters, more on DALnet and similar networks.
/quit Didn't wanna be here.
Technically, the QUIT command initiates the closure of your TCP connection to the server and exits the client program. Under some circumstances, though, the connection may be faulty and QUIT may not reach the server, or the server's acknowledgment of reception may never reach the client. In these cases, QUIT simply shuts down the client program with no visible response from the server's side.
Under ircll, DISCONNECT closes a server connection without also exiting the client. Similarly, mIRC, like most other graphical interface clients, allows a simple disconnect when you select File • Disconnect or click the leftmost icon on the toolbar.
Disconnections are frequently involuntary, with a variety of possible causes. Your client usually gives you an indication of the cause. Let's have a look at these annoying events, which can happen out of the blue.
Nickname Collisions
Nickname collisions are less common than they used to be, since modern servers don't allow collisions, malicious ones in particular, to happen too often. Collisions are still possible, though, especially under bad network conditions, but users can avoid most incidents with a little care.
A collision occurs if a server detects more than one instance of a nickname on the network.
This should not be possible and is a violation of the protocol, so the first server to detect such a thing issues a KILL command for one or both offending clients, forcing at least one of them off the network by having the server they are using disconnect them.
Collisions are identified by their characteristic messages, which your client may format to make more understandable. A typical message you might see is:
*** You have been rejected by server irc.someserver.net
Some very nasty-looking garbage sometimes follows this message. Other users on a channel you were on at the time would see something like this:
*** Signoff: SomeNick (Killed (irc.someserver.net <-irc.server.com(?)))
In this case, irc.someserver.net detected the nickname you were using, SomeNick, as in use by two different sources. Depending on the servers' and colliding clients' position on the network, the signoff message may appear in a number of different formats. The example above is a very simple one.
Operator Kill
Unless you're guilty of misbehavior, you should never get disconnected with one of these messages. These disconnections result when an IRC operator, a client with special privileges as opposed to a server, issues a KILL command for your nickname:
As a rule, IRC operators do not use KILL lightly—your client has violated the servers' or network's rules.
Operator KILL may appear in two different formats, depending on whether the operator is on the same server as you (local) or a different server (remote). Some clients exit upon receiving a KILL from a local operator. The reason for the kill almost always follows an operator KILL command; this can be arbitrary text, but more often states why you got killed. The message you see looks like this:
*** You were killed by operator EvilOper (get off my server)
Users occupying the same channels see the following, depending on whether the kill was local or remote:
*** Signoff: SomeNick (Local kill by EvilOper (get off my server))
or
*** Signoff: SomeNick (Killed (EvilOper (get off my server)))
An operator kill does not prevent you from reconnecting unless a K: line or G: line follows it, in which case you'll see a server notice like those described earlier.
Automatically reconnecting to the same server after a kill(clients has a setting for that) is not a good idea, by the way. Most operators view it as a "bouncy" client that can't take the hint that it's not welcome, and they then set a K: line.
Server Downtime
IRC servers are no more than machines and programs, and therefore are subject to malfunctions, like any computer-related system. If an operator or administrator takes down the server intentionally, you might receive a notice first, advising you to wait before reconnecting or to connect to a different server. If it simply crashes out of the blue, you'll receive no warning. In either case, the result is the same—you'll appear to lose the connection for no obvious reason. Because it takes a finite time for a server or machine to restart and begin accepting client connections again, if you attempt to reconnect immediately, you won't be able to, and your client will return the message "Connection refused," just hang, or return a network error if the machine has crashed, not just the IRC server on it.
Ping Timeout
Probably the most common signoff for a new user is the Ping timeout. Ping timeouts result when a server doesn't receive a PONG within a certain time after sending you a PING. The server sends PINGs are sent at regular intervals if the client hasn't been active—usually between 90 to 240 seconds—and should evoke a PONG from the client. If a client fails to respond to a PING within a certain time, the server considers it no longer present and closes the connection.
mIRC users will see PING? PONG! messages in their status window to indicate this is happening; other clients do not. Either way, responses are handled automatically and manual intervention is not necessary.
Connection Reset by Peer
What the heck is a peer, anyway? This apparently cryptic and confusing message is actually quite straightforward. If yours is the client being disconnected, it means the server closed the connection. If you see someone else disconnected with this message, the client closed the connection (in networking, the two connected parties are known as peers), but did not disconnect normally.
_Danilo_ [debian-tor@gateway/tor-sasl/danilo/x-68945772] has quit [Remote host closed the connection]
It isn't really very helpful, since only the end that closed the connection knows the actual reason for the closure. Compare it to losing a phone line. If the other party hung up before the conversation was through without saying goodbye, or mumbled it while hanging up, you won't really know why the call ended. You'll just know the caller is gone and you'll hang up, too.
This type of quit is also associated with some of the DoS attacks (nukes)
Excess Flood
In order to prevent the server from taking too much of a load from a single client, there is a limit to how much data a server accepts from one client within a certain amount of time. A typical value for this limit would be of the order some KBps, meaning the server automatically disconnects any client detected sending more than 1KB of data within a second. There are two possible reasons for getting disconnected like this, and you can avoid them with a little care. A well-configured client is unlikely to get disconnected for excess flooding.
The first reason is that you may really be sending too much data.
Sending text files and ASCII art to someone or to a channel may look pretty or help you make a point, but if you attempt to send it all at once, you're likely to be disconnected or, as it's better known on IRC, you flood off. The size of the file may be less than the critical limit, but file size increases with the addition of the instructions the server needs (invisible to the user) to forward the message to its recipient(s); your client adds these instructions to each message.
Unless your client has a timing mechanism that leaves an interval between messages in order to slow down the rate at which it sends messages, sending even small files may disconnect you.
The second reason for flooding off is an attack on your client or channel with the intent of forcing your client (and possibly all the others on the channel, too) to send data to the server at a fast enough rate to be disconnected. Flood protection, can prevent this.
A properly configured client never yields to this kind of attack, and most modern clients are fairly flood resistant by default.
Kill Line Active
This is the operator kill we looked at earlier, taken a step further. An operator may deem that KILL wasn't sufficient or notice that the offending client keeps reconnecting, and set a K: line just like the one mentioned ealier.
The message will be totally unambiguous, saying "Kill line active" or "K-lined," sometimes followed by a reason or the time the K: line is in effect, if it's a temporary one. If you're positive you are not at fault, then you've had a bit of unusually bad luck—the operator set a K: line for someone else who happens to be sharing a host mask with you while you're connected to the server.
Operator-set K: lines are effective immediately and result in instant disconnection of all clients matching the K: line, without allowing them to reconnect.
Not all K-lined signoffs are real—some people find it funny to quit with such a message. On DALnet servers the message is "User has been banned."
Other Types of Disconnection
Bad network connections between you and the server cause other less common disconnections. Many of these result in the message "Ping timeout" or "Connection reset by peer," but there are any number of network-related disconnections, such as "No route to host" or "Network is unreachable" or "Host is unreachable." In these cases you should check the connectivity of your local service (for example, if you're unable to retrieve documents from off-site Web servers, your local service has lost its connection to the rest of the world).
Ping and traceroute are the tools for doing this, and are widely available from most sites carrying networking software (if you're using a Windows 95 or NT or a Unix system, these utilities are almost certainly present on your system).
If your end of the connection looks all right, the failure is probably on the server's side, and connecting to a new server should solve it. Use the utilities described above to make sure the server you've selected is reachable, since in the event that part of the backbone network breaks down, you may find large segments of the Internet unreachable from where you are caused by network attacks on one of the connected machines (nukes). However, nukes look like the disconnects mentioned here and are often indistinguishable.
Finally, on the largest networks, and particularly EFnet, you may see the message "SENDQ limit exceeded" or something to that effect. This commonly means you attempted to retrieve a list of channels, and the amount of the data sent back was too great to maintain the connection between client and server. If you simply must have a list of every channel on the network, you can try changing servers in search of one that will not disconnect you, or visit irchelp.org on the Web and view the channel list there.
Channels
What has made IRC so popular is the idea of users convening in channels.
You may know them as rooms from other online chat systems, but the correct
term on IRC is channel. Still, some IRC services call them rooms, so we'll
have to live with the fact that both terms are in use. In a way, the terms
describe the difference between the old idea of entering rooms where some
sort of party is going on, and the concept of tuning into channels on a forum
similar to CB radio.
Instead of everyone connected seeing everyone else and all public messages going to all other users on the network, each user can choose to join one or more channels of his or her choice and communicate only with other users who have selected the same channel.
Channels are identified by a name, which usually reflects the topic of discussion in that channel or the kinds of people that frequent it.
The subject matter is entirely arbitrary, as is the name. Anyone can create a channel, name it whatever they like, and talk about anything they care to talk about. The only exception to this is channels on a network that enforces a policy about the kind of channels its users may create—for example, one that forbids sex channels.
In theory, a channel can have as many users as are connected to the network on which the channel exists. If a network has 10,000 clients connected, it's theoretically possible to have all 10,000 on the same channel. Not that you'll ever see any channel of this magnitude on IRC—the maximum number I've actually observed is about 2,000, which is huge enough. Just imagine trying to keep up with the combined messages of 1999 users.
Channels are highly configurable, though, and it's possible to set up even one that size so as to prevent total and utter chaos.
Channels often also have a topic—an description of the channel and its purpose or a comment related to some event on the channel itself. This is the second identifier a channel may have, but is usually not as descriptive as the name.
Channels are not required to have a topic indicating what's going on, and many don't. Many channels are quite happy with no topic at all.
Channels can be present and available throughout a network(global channels), or their presence may be limited to a single server or group of servers(local channels).
- Global channels, accessible from all servers of the given network, are invariably characterized by a leading hash mark (#) in their name.
- Local channels, which only users of a specific server may join, begin with an ampersand (&).
- A less common type of channel exists only on servers matching a certain mask, but is considered global within this group of servers. Their names begin with a hash mark, but include the server mask, appended following a colon (:). For example, #friends:*.be would be available only to people using servers matching the *.be mask—Belgian servers, since BE is the country code for Belgium. You won't often encounter these. In order for this kind of channel to work on all servers matching the *.be mask, the servers must be directly connected.
- A fourth type of channel has a plus (+) prefix, and is not available on all types of servers—only Undernet and IRCnet servers support them.
This kind of channel has the added characteristic of disallowing channel
management commands and is actually a very old feature that has been
reintroduced without too much success. The purpose of modern-day
plus channels was to offer an environment without the channel politics
and power play that usually results from having a power structure, as is
the case with global channels.
- The newest versions of IRCnet servers have an additional form of channel beginning with an exclamation mark (!), but so far most clients don't support them, and they are obscure in function and purpose.
To summarize this, a channel named #ThisChannel is global, whereas you can only reach a channel named &ThatChannel from one server.
Channels beginning with & on different servers can have the same name, without interfering with each other.
Finally, you can only reach a channel with the name #Canadians:*.ca from servers matching the mask *.ca—Canadian servers in this example.
As a matter of convenience, all channels i mention from here on will be regular global channels unless otherwise stated.
Global channels are the majority, and have many more potential uses and problems. We have already seen the different IRC networks that are not related to each other and have no interconnection.
Likewise, a channel on one network may have a counterpart on another that shares only its name. For example, the EFnet #irchelp channel is totally different from the Undernet #irchelp channel—each has its own settings, rules, users, and operators.
In some cases, the same people maintain channels with the same name on various networks, and these channels look similar. Each must be joined and maintained separately, though, and of course they require separate server connections. Now let's see how to find and join a channel.
Obtaining a List of Available Channels
All servers keep the current channel list in memory, and most allow a user to retrieve a large part of it (Attention not the whole list).
This is done using the LIST command. Depending on your client, you may also be able to sort the list and limit it to a group of channels with common characteristics.
The server, although it keeps a complete list of channels—the number of which may well exceed 20,000 channels on the largest network—also keeps track of secret channels that don't appear in a list. The operators of these secret channels have added a setting telling the server not to divulge any information regarding them or their users.
Depending on the network, between 30 and 60 percent of all channels are secret and therefore are missing from the list. This accounts for the difference between the number of channels you receive in a listing and the total number you may have noticed in the output of the LUSERS command.
The basic syntax of the LIST command is simply:
/list
and the response(because of the huge number of channels probably tour client advise you if you really want execute the list command trough an additional parameter like /list -YES in my irssi client) looks a lot like:
11:15 -!- Irssi: Doing this is not a good idea. Add -YES option to command if you really mean it
11:15 -!- Channel Users Name
11:15 -!- #myfaces 3
11:15 -!- #adva-cms 6 adva-cms: http://adva-cms.org | adva_cms 0.3.2 http://bit.ly/9SVkgB | adva-cms2 0.0.9
http://bit.ly/fI5ZPA
11:15 -!- #xomb 13 xomb exokernel project @ www.xomb.org
11:15 -!- #ganymede 3 Don't you wanna hang out and waste your life with us? See you space cowboy... You're
gonna carry that weight. Are you living in the real world?
11:15 -!- ##RonPaul-ops 5 Administration channel for #RonPaul. Discussion of channel policies and bans belongs
here. Channel policy: http://www.billstclair.com/RonPaul/channel-policy.shtml | the freenode client
is banned to here until freenode do what they said they do in banning mibbit
11:15 -!- #scala-cz 4 Programovaci jazyk Scala | www.scala-lang.org | Scala (ceske materialy)
http://jdem.cz/kevg5 | CZ Podcast 47 - Scala - http://java.cz/article/czpodcast-47-scala
11:15 -!- #phpug-karlsruhe 5
11:15 -!- #quotero 5 "New Quotero Web Site: Online. Please visit: http://www.quotero.com"
11:15 -!- #sbfuf 6 #sbfuf - 1 in 10 wins a free Pneumatic AutoFelcher!
...
Depending on your client, the information appears either in your main window or in a special channel list window(status window in case of irssi client)
.
- The number following the channel name is the number of users currently on the channel, and
- the text after the number is the channel's current topic.
- If the name of a channel is longer than ten characters (including the hash mark), many clients will truncate it. You have to change your client's settings to make it display full channel names that are longer or to make it show more of the names.
Of course, the list may already be too large, so you may want to see less of it anyway. Most clients allow you to limit the number of channels displayed: They filter the list for channels with characteristics you define by adding some parameters to the LIST command. Not all of them will apply to all clients, but you can expect a good client to support most of them. Some of the flags and parameters LIST is likely to support are as follows:
- -topic Shows only channels that have a topic set.
- -min X Skips all channels with fewer than X users.
- -max Y Skips all channels with more than Y users.
- -wide Displays a list with full channel names and the number of users. The topic, if any, is ignored.
- #channel Shows the list entry for #channel only.
- *string* Shows only list entries containing string in the
channel name.
LISTing is often easier said than done. You may encounter a variety of problems while trying to get a list of channels.
Disconnecting When Using LIST
Oops—you asked for a list, got 150 or 300 channels, maybe even none, and got booted from the server. This is an extremely common problem, especially on regular dial-up connections to one of the major networks.
It results from a combination of the speed of your connection to the server, the server's setup, and the size of the list itself. On the larger networks, there may be as many as 10,000 channels on the list the server returns. This is a hefty amount of data, and a regular dial-up connection often has trouble handling it.
The disconnection occurs
- when data waiting to go to a destination exceeds the maximum the server's configuration allows, or
- when it takes the client so long to receive the list that a Ping timeout occurs.
Each server sets the values for the maximum amount of data to queue for a client and the Ping interval separately, which explains why you can use LIST with no problems on one server while you get disconnected on another.
If the maximum amount of data allowed is less than the size of the list, many connections, especially dial-ups, can't absorb the excess data fast enough to bring the contents of the buffer below the maximum allowed. Often the server's administration may not be aware of the problem—server administrators tend to have very fast connections to the server, and most of them rarely use LIST since they know their way around well.
- Sending an email to the server asking its administrators to raise the limit for your connection class may prompt them to solve this problem.
- Trying to reduce the amount of data by requesting a limited list will not help—for any listing concerning more than an individual channel, the server sends the whole list, and your client sorts it and displays the part you want to see.
Since it's generally easier for servers to provide a solution to this problem on their end than to ask all users to increase their connection's bandwidth (which would be unrealistic, considering the extra cost for both bandwidth and hardware on the user's end), server administrators often cooperate if you bring the problem to their attention. As far as the server software is concerned, only the Undernet and DALnet code and versions based on it do a limited amount of filtering the list before sending it to the client, thus making it possible to reduce the amount of
data a server returns.
Since you're probably not inclined to wait the hours or days it will take the server to fix the problem, you should try a few more servers on the network and see if any return a list without disconnecting you.
Strange Channel Names
Once you get a large list from a server, you'll probably notice a number of channels with what appear to be non-sensical names made up of sequences of strange characters. The majority of these are actually quite normal channels. What you are seeing is the ASCII rendition of the Japanese Kanji characters that make up the channel name. These are identifiable as such because they contain many square bracket ([), dollar sign ($), and B characters. Korean and Chinese channels look similar.
Sometimes you'll also see apparently normal names with one or two unusual characters. These are channels that use a slightly different, although Latin-based, character set. Many of these are in a Nordic language; others may be German, French, Portuguese, or Spanish. In order to join one of these, you have to switch character sets, unless your upper character set (character codes 128 to 255) includes these particular characters and you can easily access it.
- Windows users should be able to reproduce them without too much trouble.
- IrcII-based clients can produce most of those characters using the DIGRAPH command. Hebrew, Cyrillic, Arabic, and Greek generally translate to a series of vowels interspersed with other characters.
Argh! The List Keeps Scrolling Off and I Miss Most of It
Solving this little problem depends on whether your client can pause during the display of the list. Some older clients aren't geared to handle the length lists can reach nowadays. In other clients, it's simply a missing feature.
If you're using ircll, the process of making the list display one screen at a time is fairly simple:
/set hold_mode on
/list [flags] [parameters]
This makes the display pause after each screenful of entries. Press the ENTER key to bring up the next screen. If you think you've seen enough, use the FLUSH command to clear the remaining part of the list. Use:
/set hold_mode off
to keep the display from pausing after every screenful, although it isn't a problem if you leave hold_mode on for the whole session—under some circumstances you may want it on anyway.
With other clients, you'll have to rely on the client's scrolling features, if any. Most, including mIRC, open a new window to display the list, and you can use the scroll bar to reach information that has scrolled off.
I Give Up—Nothing Is Working
It's unlikely to happen on the smaller networks, but sometimes on the larger networks things simply refuse to work for you. Two of the major networks have a Web service you can contact to get a fairly current list of channels. EFnet's #irchelp team provides one. IRCnet has its own, which the administrator of the network's main Swedish server creates and hosts. Both these services are easy to use, updated frequently, and searchable. Normally they work fine, but they depend on a single server for the listing they take at regular intervals. Any negative conditions (such as a netsplit) affecting their server at the time they take the list has repercussions on the list.
Here are the channel listing services on the Web:
- ... EFnet
- ... IRCnet
- ... Many other networks
- http://users.dal.net DALnet(must be a registered user)
Joining a Channel
Becoming part of a channel is simple. With the JOIN or CHANNEL command, your client sends a JOIN to your server, which in turn checks to see whether you have permission to join the channel you specified. Let's say you want to join a channel named #somechannel (remember that the hash mark is an integral part of the channel name, and you must use it). The command is simple:
/join #boinc-it
The server runs a brief check on the channel's settings and decides whether you may join it—usually you can for a public channel. If the server accepts your JOIN command, you'll see code resembling this:
23:06 -!- harrykar [~harrykar@unaffiliated/harrykar] has joined #boinc-it
23:06 -!- Topic for #boinc-it: Canale Italiano Ufficiale di BOINC - http://www.boincitaly.org/ -
http://it.wikipedia.org/wiki/Berkeley_Open_Infrastructure_for_Network_Computing
23:06 -!- Topic set by _Danilo_ [~mdt@unaffiliated/danilo/x-728421] [Sat Feb 13 17:00:10 2010]
23:06 [Users #boinc-it] Roland_d~
23:06 [@ChanServ] [+boinc-it] [ _Danilo_] [ CoderForLife] [ harrykar] [ Simone]
23:06 -!- Irssi: #boinc-it: Total of 6 nicks [1 ops, 0 halfops, 1 voices, 4 normal]
23:06 -!- Channel #boinc-it created Fri Jan 29 16:36:58 2010
23:06 -!- Irssi: Join to #boinc-it was synced in 1 secs
23:06 -!- Home page for #boinc-it:
http://it.wikipedia.org/wiki/Berkeley_Open_Infrastructure_for_Network_Computing
or in ircII client
*** Apatrix (apatrix@ircd.webbernet.net) has joined channel #irchelp
*** Users on ttirchelp:
Apatrix @>Vamps elib @Lindy_ @wmono @Garfr @MHz ^turtle @>WishBone gDemiShade (Wolo
*** Topic for ttirchelp: Ask your IRC question or visit
www.irchelp.org
*** #irchelp Garfr 917596918
*** ttirchelp 884520350
This shows you the nickname of all the channel's users, which now include you, and the nickname and host mask of the user who just joined the channel—you again. The lower two lines look a bit cryptic, but this is only because I took the example from a client who does not translate server jargon into something readable. mIRC,xchat is more helpful and translates them into something more understandable.
The first of these cryptic lines shows who set the current channel topic and when. The second line is the channel's time stamp, which says when it was created. Both of these times are expressed in "epoch" time—essentially, seconds elapsed since midnight, Greenwich mean time, on January 1,1970. This is the standard way of time keeping on the Internet. Most clients by default convert these time stamps into more readable standard (and local) time.
As you see, there are 11 nicknames listed. The number of users could of course be a lot higher and even range into the hundreds, with a screenful or more of nicknames appearing. Note that the at (@) sign before nine of the nicknames is not part of the nick, but indicates channel operator status, which we'll look at a bit later on. Other clients, such as ircle, use a different color for nicknames with channel op status (ircle displays them in red). Some clients—mIRC, for example—open a new window for the channel, along with a list of nicknames. Messages sent to the channel appear in the new window, and the channel's vital statistics show up in the status window.
Here you've been told to use /join #channel—the complete command line. Depending on your client, there may be one or more shortcuts(JOIN aliases) to joining a channel. You may be able to add the channel's name to a list stored and loaded along with the client, and join a channel by calling up the list and clicking the channel or by using a shorter form of the command itself. A typical example many clients and add-on scripts use is /j channel. Note the lack of the otherwise omnipresent hash mark. The client hasn't left it out—the client will add it and the server will receive the complete JOIN #channel command.
In the beginning, though, it's better to familiarize yourself with the real commands. This way you can use IRC from practically any client and will not depend on a single platform or client.
Most channels are public and let you join with no more than the JOIN command, but this isn't always the case. Let's have a look at the possible snags you may run into.
No Such Channel
You're positive that channel exists! Sure it does—but consider what we said a paragraph ago about the correct and full syntax of the JOIN command. The channel name you specified didn't begin with a valid character. The /join #somechannel command works, and /j somechannel might also, but /join somechannel will not, unless you have a strange piece of add-on scripting (which you shouldn't) or an ultrasmart client that understands your mistakes and corrects them, which naturally doesn't teach you much.
So, depending on your client, remember to use the hash mark where it's needed. In this case, you forgot it.
How Did I End Up on the Channel #?
You typed a space between the hash mark (#) and the channel name. Try it again without the space. # is a valid channel name on its own.
Banned from Channel
This is not unusual, especially if you've encountered a few K: lines while connecting to a server. In such a case you can be fairly sure others consider your provider or host a source of trouble and think its users should be kept off servers and out of channels.
You'll get this response to your JOIN command if the server sees that your user mask matches an entry on the channel's banned list. This straightforward message says you're banned from the channel. Less explicit clients just tell you you're "unable to join channel (+b)."
This may not seem very enlightening—what the devil is +b and how on
earth did it get there? A channel's operators set bans by adding a +b channel mode
setting for a certain nickname and/or host mask.
So +b means that you are banned from the channel. Channel bans operate independently—each channel has a separate list of bans—and they last until the channel closes or one of its operators removes them. If you have never been to the channel, obviously you didn't cause the ban to be set. Rather, it was the same local obnoxious user you glimpsed while you were looking at the K: lines eralier. If you want to be sure, though, you can look at the channel's ban list when you're not on the channel, with the following command:
/mode #channel b
Check the list returned and see which entry matches your host mask.
If there are a lot of bans affecting whole domains or even *!*@* (which of course matches everything), the channel may have been attacked and taken over.
We'll deal with takeovers later on for now, don't panic, just pick a new channel. After all, it's always better to be somewhere where you're welcome. Don't insist enjoining the channel. You'll most likely fail—you will just feel frustrated, and the ban will be renewed.
Users of large Internet providers like AOL, Netcom, and AT&T are more likely to encounter this problem. The explanation is simple:
The more users a provider has, the more idiots and abusers use its services and make the site unwelcome. If the provider also uses an addressing system that makes it hard to ban only a specific part of it, channel operators eventually end up banning the entire site in order to rid themselves of a single annoying user.
It's not fair to the rest of the users, but channel operators have this right, and some see it as their duty toward the channel's users. They do as they see fit for the purpose of maintaining order on their channel. AOL users in particular get the worst deal because of the way their dynamic IP addressing works: The pool of addresses from which it draws is immense, and an abuser can have a radically different address each time he or she connects. This doesn't leave channel operators with much choice.
Bad Channel Key
One way those managing the channel safeguard its privacy is by setting a password that the user wishing to join must supply. All servers store this password and compare it with all JOINs for that channel. If the user doesn't supply any password or sends one that doesn't match the existing password, the server forbids the user to join and gives the error message "Bad channel key." If you do know the password—known as the key—join the channel as follows:
/join #channel keyword
Channel Is Full
Another feature used for running a channel is the ability to limit the total number of users the channel may have. In this case, the server checks the current number of users on the channel against the maximum limit set and doesn't allow anyone to join if this limit has been reached.
Kick or Ban after Joining
Because of the limited number of bans a single channel may have, larger channels often also have an informal ban list.
One or more clients on the channel, often robot clients, keep their own ban list independent of the current channel ban list, and check each user attempting to join against this list.
When the client sees an unwanted user, it bans that person and kicks him or her off the channel automatically. Bans set in this way usually don't last long—most of these robots also automatically remove the ban after a while to avoid cluttering the available space on the ban list and to leave a few slots open for nonregular bans that may be necessary.
It's essentially a combination of a ban (+b), followed by a KICK command—these are separate commands, so you will first see a ban matching your host mask, then you'll get thrown out of the channel. The command generally looks like this:
*** Mode change "+b *!*@my.provider.com" by MeanBot
*** You have been kicked from channel #Somewhere by MeanBot (Co
sit in a corner.)
This type of ban happens for the same reasons as a regular ban.
I Joined a Channel on the List and It's Empty
Unless it was a channel with very few users, who may all have left by the time you read the list and joined, the reason for this appears in the list itself. The client often truncates long channel names, so what you saw was not the full name of the channel but only its beginning.
One example of a channel that used to be particularly confusing was a channel named #marriages—users kept joining it and finding it empty, despite the fact that a fair number of users appeared on the list. This is a good example of how a truncated channel name that looks like a complete name can be misleading. Further investigation showed that the name of the channel was really #marriagesex, which most of those users had absolutely no intention of joining.
Another cause for this could be a netsplit—during the time it took for you to receive and read the list and attempt to join the channel, your server disconnected from the rest, effectively emptying the channel as far as your server is concerned. They should be back within minutes—check LUSERS to confirm that it's a split and not some other problem. If the total number of users and server is much lower than it should be or your own servers says it has no servers
connected to it, this is the case.
Nickname or Channel Is Currently Unavailable
This message is particular to servers running IRCnet code and is technically very similar to the nick delay problem.
This condition, known as channel delay (CD), occurs when the channel loses its operators by irregular means and is empty—either its last operator becomes the victim of a KILL command, or a netsplit leaves all operators on the other side and no users on your side.
The channel should open again as soon as the split is fixed and the operators return, as viewed from your server. If they don't return within a certain time (a minimum of 15 minutes), the CD expires and the channel opens again anyway.
Each server implements CD individually, so another server will allow you to join if the circumstances causing the delay are not present according to that server.
Invite-Only
This means the channel has been set to allow only users who have received an invitation from one of the channel's operators to join. The server checks whether there is an invitation for you to join the channel and forbids you to join if there is none. If you are invited, you see a line like this:
*** Inviter invites you to channel #friends
The invitation stands for as long as you're connected to the server. If you disconnect from the server for any reason, you'll need a new invitation to join the channel. Obviously, the users of an invite-only channel desire their privacy and often also set it as secret.
Trying to obtain an invitation is more trouble than it's worth, especially if you haven't been on that channel before. You would have to find and contact one of the channel's operators, but you won't get much better results than if you were trying to get into a house when the owners have declared they want no visitors.
Who Is on the Channel?
Having successfully joined a channel and seen the nicknames of the users on it, you'll probably want to know more about the people who are there with you.
If you just want to see the list of asterisked (*) nicknames again, use the NAMES command:
/names #channel
Some clients let you substitute an asterisk for the current channel:
/names *
This command returns a list of nicknames the same as the one you saw right after joining the channel. If users have left or joined the channel since you joined it, the NAMES list reflects these changes.
WARNING: Do not use NAMES without giving a parameter!
If you're using mIRC, xChat, etc. you generally won't need the NAMES command, since you'll be able to see all nicknames on the channel by scrolling through the list on the right-hand side of the channel window. Other graphical clients display it on the left-hand side.
For a more detailed list of everyone on the channel, you need the WHO command. This takes the same parameters as NAMES, but some clients allow additional filtering of its output. Here's a typical WHO list, assuming you're on channel
16:43 -!- #test benenenene H+ 0 d1065206@gateway/web/freenode/ip.209.6.82.6 [collab.or8.net/209.6.82.6 -
http://webchat.freenod]
16:43 -!- #test testuserz H+ 0 ~testuser@essential029.xirvik.com [Unknown]
16:43 -!- #test niekie H+ 0 ~niek@CAcert/Assurer/niekie [Niek Bergman]
16:43 -!- #test qelo G+ 0 ~qelo@89-76-187-165.dynamic.chello.pl [Grzegorz Anielak]
16:43 -!- #test abchirk H+ 0 ~abchirk@f052204218.adsl.alicedsl.de [Unknown]
16:43 -!- #test Lxz H+ 0 ~Linuxerz@core.elitter.net [Eggdrop Linuxerz]
16:43 -!- #test sdx23 G+ 0 ~sdx23@unaffiliated/sdx23 [23]
16:43 -!- #test xnt14 G+ 0 ~xnt14@unaffiliated/xnt14 [XNT 14]
16:43 -!- #test azizLIGHTS H+ 0 ~azizLIGHT@ec2-50-17-254-25.compute-1.amazonaws.com [Aziz]
16:43 -!- #test Pira G+ 0 ~Runner@178.63.101.171 [Meinst mit WHOIS bekommste mehr raus aus mir????
D] End of /WHO list
Right, let's try and make some sense out of these cryptic lines. The first bit is obviously the name of the channel and the second is the user's nickname. The fourth bit should be the address, but what on earth is the rest?
In the third column, you'll see one or more characters explaining the user's status as far as the server is concerned. It contains one of two characters—either G or H—to indicate whether that user has declared himself gone (used the AWAY command to indicate his or her absence from the keyboard) or is here. This doesn't mean much, since many people never bother to set themselves away when leaving. I often forget to set myself here again when I return.
One or more of the following characters may follow the leading H: or G: an at sign, an asterisk, and a plus sign.
- The at sign indicates that user is an operator of the channel.
- The asterisk stands for IRC (server) operator.
- Finally, the plus sign means the user has a voice on a moderated channel
- Depending on the type of server, you may also see a couple of different characters, most commonly a "d", which means the client is in "dumb" mode and is not following the channel's conversation. This mode is used mainly for service robots and is available only on Undernet and similar networks.
The final part in the parentheses is no more than the ircname (or realname), but (not ever) the number in front of it (i.e. #irchelp Apatrix H@ alc@egnatia.ee.auth.gr (6 Agent of Chaos) ) is less easy to explain.
This is the distance between your server and that user's server, measured in server hops—how many server links connect you and the other user. For the client performing the WHO command, the value is always 0, since there is no way in the world it could be on a different server than itself. Whether you see the number depends on the client's setup.
Channel Operators
What are channel operators and what's so special about them? Are they people? Are they machines? Are they something else we dare not imagine?
Channel operators are users with certain privileges on a channel. They control the channel by using a special set of commands that can:
- change the channel's settings or modes and topic,
- invite people to the channel, or remove unwanted users.
They are usually called ops (the most widely used expression)
for short—other terms are chanops or chops.
Ops don't appear on a channel magically. Something has to make a user a channel operator. There are three ways of obtaining channel op status.
- The first is being the first user to join a channel, in which case the server automatically gives you ops.
- The second is getting assigned op status by a user who already is an op or by identifying yourself to a channel server that will check whether you are an authorized user and, if so, assign you op status.
- The third method, possible only on networks with a channel service, involves identifying yourself to the service with a special password.
A user with ops
is basically just a channel setting that means
this user has operator privileges. An at sign (@) prefixes that user's nickname whenever it appears in conjunction with the channel.
Channel ops last as long as the opped client is present on the channel. If the user leaves the channel for any reason, he or she must obtain ops again by one of the means mentioned above.
A channel may have any number of ops—from no op at all, to every user having ops.
Only the number of users on the channel limits the potential number of ops. Having a channel with no ops can be a problem, though. Without ops, no one can change the settings of a channel, or remove obnoxious users from it.
The power of a channel operator over the channel is absolute and subject to control only by other operators. Unless another op questions the op's actions, he or she is free to change the modes, kick people, ban them, and give out ops to others at will.
Some networks with a channel service allow a hierarchy of ops on a channel and permit a super-op or founder to assume a higher level of control (in which case the rule of absolute power applies to a single person). Apart from that case, the ops of a channel are equal and may also deop each other—that is, remove operator status from a user who is an op at the time. This technically also changes the channel's settings (makes a mode change).
You might wonder how a channel keeps its operators with people coming and going all the time. In the case of larger channels with a lot of regular users, there are enough people to keep at least one regular operator on the channel at all times.
Many channels, especially medium and small ones, rely on a different method of keeping the ops on a channel. You'll soon encounter one of the tools for doing this.
Channel Bots
Bots (short for robots) are the prime tool for maintaining a channel op at all times even if none of the regular users is on the channel. Also known as automatons (automata if you're into linguistic semantics), IRC bots are programs with a variety of uses, not all of them innocent. They are used most widely as channel management tools.
A channel bot doesn't look any different from a real live user on IRC. Technically, it's a client. Its purpose is to sit on a channel day in and day out and perform channel management functions, either by monitoring channel events and reacting to them or by following instructions from users authorized to send it commands.
The bot needs to maintain a constant network connection, so most bots run on Unix machines with such a connection, independent of whether their owner is logged into the machine or not. Dial-ups are generally not suitable for running bots, since they require constant use of a phone line to stay connected. Also, the bandwidth of a plain modem connection is generally a fraction of that of a machine with a permanent link, making a bot (or any other client on it) less stable and more susceptible to attacks.
Since one purpose of bots is to ward off possible attacks on a channel, this can be a strong liability. Cable and DSL are better options.
Since, all too often people use bots for much more than just channel maintenance, many servers have a policy forbidding users to connect hosts and a standing order for the server's operators to "shoot on sight" or even K: line any address found running one. Another reason for this is the large number of badly configured bots: They can mess up channels and cause users to look for the server's operators to kill it off; they use up network resources by triggering loops; and "vanity" bots hold an entire channel and take up a full-time connection that real users might need during peak hours.
I have nothing against bots on principle. As an IRC operator, though, I've had many opportunities to observe how people use them to harass others. In my opinion, the problems bots create are at least equal to the benefits users gain by their presence. It's simply not feasible to sort them into good bots and bad bots, so banning them all is a valid option many server administrators resort to so they can curb abuse.
A well-configured bot can help maintain a secure channel. You can even program them to entertain or inform a channel's regulars and visitors with funny automated responses or timed announcements. You can usually identify a channel bot by the way it remains in the channel saying nothing or limiting itself to obviously automatic responses.
Another characteristic is that they may immediately op a user upon joining, announce the user's presence, or send joining people an automated message (which isn't really smart but is quite popular).
Bots are special programs that act as unsupervised clients on IRC.
With the high level of sophistication of some modern clients and add-on scripts, these programs are often as effective as a bot. The line between a high-powered script and a bot is growing thinner all the time, and many users already prefer the script method to keep their channels going.
Moderated Channels and + Voice
Moderated channels don't quite fit the common definition of moderation. On a moderated forum such as a mailing list, a person who acts as the moderator must approve contributions, and may forward or reject a posting.
Moderation on an IRC channel merely allows some users to send messages to it and prevents others from doing so.
The sender of a message must be an operator or approved by an operator, but the message itself is not submitted for approval before it's sent to the channel.
Moderated channels are used for IRC classes, news channels, guest lectures, IRC weddings, and other events where attendance is expected to be high but the channel owners want to keep the traffic low.
Some IRC networks such as GlobalChat have guest lectures where the moderator and the guest lecturer have voices. When you submit a question, the moderator approves the question by typing it to the channel, and the lecturer answers it on the channel.
Moderated channels have an additional setting permitting only certain users to send messages to the channel. Those who may speak on a moderated channel are its operators and those users to whom they have given a voice. This voice is a channel mode, like operator status, but permits the user to speak without giving him or her full operator privileges.
On the WHO list, a voiced user appears with a plus sign in the same place as an operator's at sign. Ops can give or remove the voice just as they can channel ops, and the voice is also valid for as long as the client is on the channel.
A user can have a voice and ops at the same time. This is really redundant, since an op has a voice anyway and is useful only if the user's ops are taken while still on the moderated channel.
As long as the user has ops, the voice is not visible, but is known to the server. If the ops are removed and only the voice remains, the server displays the plus sign indicating the user has a voice.
Channel Events
In addition to the messages sent to the channel by the people on it, many others appear, and some look very cryptic. These notices are known as events and indicate a change in the channel's user list or characteristics. Let's have a look at the various notices you may see while on a channel—mIRC users normally see some of them in the status window, but can set the client to display some or all in the channel window as well by selecting Options, then IRC Switches from the File menu.
Mode Changes
These are notices indicating a change to the channel's settings (modes). One of the channel's operators usually performs mode changes; these may be one of the changes I've already mentioned or others I'll discuss later.A typical mode change looks like this:
*** Mode change "+m" on channel #Somewhere by ChannelOp
This says what kind of change was made on which channel and by whom. In this example, the mode change was +m, which means moderated mode. The op named ChannelOp added moderated mode to the channel named #Somewhere.
In some cases a server rather than a user may make the mode change. This is a consequence of net joins.
On networks with channel services, one of these services may make the mode change, following instructions from the channel's owner or another authorized person.
The service robot isn't necessarily visible on the channel.
Joins, Parts, and Quits
Each time a new user joins the channel or an existing user exits by either leaving the channel or quitting IRC altogether, the channel will be sent a notice describing the change.
A typical join notice looks just like the one you saw right after joining the channel and contains the nickname and host mask of the user joining and the name of the channel he or she just joined:
*** Brenni (s@ti33a95-0l82.dialup.online.no) has joined channel
#irchelp
In the same way, the server also announces a user's departure from the channel:
*** Brenni has left channel #irchelp
As in this example, not all clients display the user (a host of the user leaving. As we saw earlier
when a user quits IRC, any channel he or she is on is sent a notice. If the user adds a message to the quit, this also appears here.
As with regular parts, some clients show the host mask of the client signing off while others don't.
*** Signoff: Hello4lm (Quit: Leaving)
Nick Changes
If any user on the channel changes his or her nick with the NICK command, the channel will show this self-explanatory message:
*** Cuest53962 is now known as sOuLfLy
Kicks
Kicks appear if one of the operators decides a user should not be on the channel and uses the KICK command.
09:18 < Stric> harrykar: is there anything else? if not, we'd prefer if you not idle in here.
09:21 < Stric> harrykar: welcome back if so.. bye
09:21 -!- mode/#opers [+o Stric] by Stric
09:21 -!- harrykar was kicked from #opers by Stric [..]
This tells the channel who got kicked by whom, on which channel, and why. The explanation in the parenthesis is meant to inform the channel's users and its other operators of the reason for the kick. It can actually be arbitrary text and is just as often used to add smart comments for the entertainment of the channel if the actual reason for the kick is obvious. Many channels object to people idling—sitting on the channel saying nothing for a long time—and will kick them after a while(as is the case in the example above).
Leaving a Channel
You leave a channel by simply using the PART or LEAVE commands, whichever your client supports, or closing the channel window if your client opens separate windows for each channel.
If your client (and the server) supports it, you can also leave a parting message in the same way you leave a message with QUIT. If it doesn't, you might be able to add this feature with an alias or send it with a raw server command.
Whether you use PART or LEAVE is not important as long as your client understands both. But the server needs PART (PART is a server command, while LEAVE is only a client command and changes to PART when it's sent to the server), so if you intend to use a raw server command to leave a channel, you must use PART. This is the simplest form of a command to leave a channel:
/part #somewhere
If your client lets you substitute an asterisk for the current channel,
/leave *
makes you leave your current channel. Some types of server also let you add a parting message just as you can with QUIT.
Joining Multiple Channels
Most clients let you join more than one channel at the same time. If your client does, you can be on as many channels simultaneously as the server permits. The number is usually between 10 and 14 but can also be higher—not that you'll often find yourself following conversations on 14 channels.
You can join more than one channel with a single JOIN command, or you can join them one at a time. The JOIN command takes a comma separated list of channels:
/join #somewhere,#elsewhere,#nowhere
If you do this, you'll see a multiple version of the events you saw when joining a single channel—three different NAMES lists, three JOIN commands for your client, and three new windows will open if you're using a client with a window for each channel.
IrcII users may have to change one of the client's settings in order to join more than one channel. This command is
/set novice off
If NOVICE is on, joining a channel automatically makes you leave the previous one. Add this setting to your .ircrc file on setting up the client if you're confident you can handle multiple channels.
Switching between Multiple Channels
The conventional way of changing channels without leaving any is to JOIN the channel again, although you're already on it. This makes that channel the current one. On a client with separate windows for each channel, you simply select the window corresponding to the channel to which you want to switch.
With ircll, you need another line of low-level scripting using the BIND command.
The BIND command lets you bind a key press to a function. In this case, the desired function is called switch_channels. Select a control key that you aren't using for anything else (I suggest CTRL-V) and bind it to the function with the following line:
/bind ^\ switch_channels
Note that a caret (^) represents the CTRL key. If you press CTRL-back slash ( ^ \), the client cycles through all the channels you're on until you reach the one you want. This is another command you should add to your .ircrc file.
In irssi client you must press ALT+arrow keys or ALT+#channel number(for channels 1-10) and ALT+[Q-P] (for channels 11-20) or /w number(>20)
An mIRC user can also define hot keys to perform functions like this.
Channel 0
The only channel not characterized by a leading symbol is the single channel many call "the salt of IRC," because this is the channel every user automatically joins when connecting. This channel is known as channel 0 or the null channel. Every client connecting to a server finds itself in channel 0. From there on the client can proceed to join other channels, or remain there and communicate with individual users.
Channel 0 is also different as far as communications go. On this channel other users are visible only if they have usermode -i set, and you can't send public messages to it. Many commands you can use on normal channels will also fail to work. If you choose to join channel 0 while you're on any other channels, you'll leave those channels.
JOIN 0 is a nifty way of simultaneously leaving all the channels you're on.
The Channel #2,000 Trick
Some less well-meaning people like to entertain themselves by conspicuously sitting on a channel named #2,000 or something else with a comma in it and inviting others to join that channel.
Remember, though, that the comma is a separator and not a legal character in a channel's name. Joining channel #2,000 makes you join channel #2 and channel 000—and you just saw what channel 0 does.
How did those people get onto that channel?
The answer is simple: The comma is not a comma. I don't know the purpose of having a comma-like character (identical to a comma but not a comma) in the character set, but this is how things are. You can bring up this special character with the ALT-0130 key combination under Windows (you can also view it in the Character Map).
IrcII users can produce it with the comma-comma („) digraph. This proves that what looks like a duck and quacks like a duck isn't always a duck.
mIRC versions 5.5 and later prevent you from joining a channel this way. Its
author decided people were having too much fun "playing" with newbies.
Netsplits and Lag
It's time to meet a legendary figure the Lag Monster. No one has ever seen this insidious creature, but it is believed to lurk in the lines and gobble data packets as they pass by. The result of this is the annoying phenomenon known as lag. You can usually tell when this beast is nearby because your messages take longer and longer to reach your friends—you're lagged! According to rumor, the lag monster sometimes eats whole servers and spits them out (too much silicon in the diet is not good, even for a horrible monster). Let's investigate the activities of the most hated creature on IRC.
Netsplits
While this phenomenon is not directly related to channels, you're bound to encounter a netsplit sooner or later while you're on a channel and you may wonder what it means and what causes it. Some of the events you may have observed so far could also be related to netsplits.
23:30 -!- Netsplit irc.poop.nl <-> gnome-irc.gopc.net quits: cj
23:31 -!- Netsplit over, joins: cj
They affect the whole network, including channels, and result from server connectivity problems, servers or their machines going down, or operator intervention in the network's routing. Users on a channel can detect a netsplit from the characteristic quit messages.
05:07 -!- Netsplit *.net <-> *.split quits: _Danilo_, +boinc-it, @ChanServ, CoderForLife, PunkOdissey[Out]
05:14 -!- Netsplit over, joins: _Danilo_, @ChanServ
05:18 -!- CoderForLife [~Miranda@unaffiliated/coderforlife] has joined #boinc-it
05:18 -!- CoderForLife is "Don" on #boinc-it
05:18 -!- CoderForLife is Don
05:19 -!- PunkOdissey[Out] is "PunkOdissey" on #boinc-it
05:19 -!- PunkOdissey[Out] (PunkOdissey) [punkodisse@komodo.contextshift.eu] has joined #boinc-it
05:20 -!- mode/#boinc-it [+v boinc-it] by ChanServ
05:20 -!- boinc-it is "boinc-it" on +#boinc-it
05:20 -!- boinc-it (boinc-it) [~boinc-it@unaffiliated/danilo/x-728421/bot/boinc-it] has joined #boinc-it
06:09 -!- _Danilo_ [debian-tor@gateway/tor-sasl/danilo/x-68945772] has quit [Ping timeout: 246 seconds]
06:14 -!- _Danilo_ is "Danilo" on #xchat #openoffice.org-it #lp-it #libreoffice-it #gnewsense #gnash #gimp-it
#freenode #debian-it #debian #boinc-it #boinc
06:14 -!- _Danilo_ (Danilo) [debian-tor@gateway/tor-sasl/danilo/x-68945772] has joined #boinc-it
08:19 -!- PunkOdissey[Out] [punkodisse@komodo.contextshift.eu] has quit [Quit: changing servers]
08:20 -!- PunkOdissey[Out] is "PunkOdissey" on #boinc-it
08:20 -!- PunkOdissey[Out] (PunkOdissey) [punkodisse@komodo.contextshift.eu] has joined #boinc-it
If you see one or more users sign off with the names of two servers as the quit message, this indicates they were on the other end of a server link that just broke. The names of the servers tell you which link that was.
On IRCnet and similar servers, the quit reason contains the server on your side of the split (which is still visible to you) and the server of the user who's "signing off." All other server types show the broken link.
A netsplit occurs when two servers lose their link for any reason. When this happens, a server or group of servers loses contact with the rest, and both parts function as separate networks.
Let's look at a small network diagram to make it clearer:
Say the link between New York and Chicago breaks. As a result, Chicago and all the servers behind it (Seattle, Denver, and Los Angeles) lose sight of New York and everything behind it (Washington, London, Paris, and Madrid), and vice versa. In effect, this creates two separate networks. One side sees all servers of the other side disconnect and all clients on those servers signing off as a result. A client on the Paris server can no longer see a client on the Denver server, and vice versa.
Here's another example: The link between Denver and Los Angeles drops. Now Los Angeles is alone. Exactly the same result applies in this case—what changes is the proportional size of the split parts.
In a more serious case, the New York server would crash and consequently drop all its links. The network would split into four pieces:
Washington and London are both alone; Paris and Madrid form a small network of their own; and Seattle, Chicago, Denver, and Los Angeles form another part. No part can see what's going on with the others. They don't even know that the rest of the Net is fragmented too (unless an observer noticed that the reason was a server crash).
Server-Server Lag
Lag is another network problem that, while it's not directly related to channels, can be as much of a nuisance as netsplits.
Lag and netsplits often go hand in hand; one may cause the other, leading to a vicious circle that can create tremendous chaos on a big network if it affects a large part of the Internet, including some of its central servers.
A high load on the server machine, resulting in slow processing of network traffic, can cause lag, but more often it is due to a network fault that slows down the transmission of data between servers. As a result, the servers on one or both sides of the defective link start queuing data destined for the other end, putting all new messages at the end of the queue. This results in delayed transmission. If this happens to a centrally located hub server that has a lot of both inbound and outbound traffic, it affects much of the network's communication.
If the amount of data queued for a single destination server exceeds the maximum permitted by the server's configuration, the server closes the link to the other server, resulting in a netsplit.
When the link is restored, all client and server connections, which one side or the other considers to have quit, are retransmitted, along with information about the channels' users and modes. This is a large amount of data, and if the destination server does not receive and process it fast enough, it can end up queued, in which case we have a new round of lag and the potential for more netsplits.
If the servers' automatic connection features fail to create a new working set of links, the network's IRC operators have to intervene and work around the problem by placing the lagged servers at a less central point of the Internet and using alternate servers as the main hubs.
Client-Server Lag
Another cause of delays in message transmission is client-server lag. You can detect this by using CTCP PING on yourself. If this command returns a long time, the problem is either the network connection between the client and the server or a heavy load on either of the two machines.
Following a net join, the servers don't resend some information, mainly to reduce the amount of data transferred during the sync. Most types of server will not resend users' away status and channel topics, so you would have to reset these after the rejoin in order to be visible throughout the network.
While you may not even notice the fact that the away status doesn't propagate, you'll often observe that you can't see a channel topic other users on the same channel say is there, or vice versa.
COMMUNICATION
Now that you've successfully made a connection to an IRC server and
joined a channel, you're likely to see all sorts of different messages, strange and
plain, scroll down your screen. It's quite all right to remain silent for a while and simply follow the conversation.
Types of Messages You May Receive
There are a number of different kinds of messages you'll receive, each with its own significance and use. Different message types are characterized by their appearance—either they show up on a certain part of the screen or they contain certain characters indicating their nature. Your client affects how they look as well. Here's how to identify the various message types.
Public Messages on a Channel
These are the probably the first messages you'll see, and they're what IRC is all about. Any user can send a message to the channel if the channel's settings permit it (most channels do). A public message appears in your main screen or channel window like this:
23:19 < harrykar> Osiris offers a full-text search engine that allows searching across all portals' content.
The user nicknamed harrykar sent this message to the channel. The angle brackets (< >), which characterize a public message, contain the nickname of the sender. The message itself follows.
If your client also opens separate windows for nonpublic messages, these may also appear in brackets in the corresponding window, rather than appearing in a different display format in the public message window.
Private Messages
It's possible to send a message to a single user or selected group of users without having to join a separate channel. If you have any experience with BBSs and similar chat systems, you'll know this as whispering. The recipient of the message will see something like this:
*Whisperer* Hi! This is a private message that only you can see.
The asterisks (*) around the nickname mean this is a private message, not visible to anyone else on the channel. You don't even have to be on a channel to receive such messages.
If you're running a client that opens a new window upon receiving a private message and dedicates it to the sender, there may be brackets around the messages. In this case the window in which private messages appear identifies them as such. In fact, they may appear in a number of different formats depending on the client, but will always be noticeably different from public messages.
Notices
A bot or other kind of service (such as a nickname or channel service) sends notices, usually as a response to something you sent but sometimes with informative content.
Some people like to use them to confuse new users by sending them as an unusual kind of private message. On DALnet, this has developed into an epidemic. I don't know why, but people on that particular network tend to use notices instead of regular messages, probably because a lot of mIRC users don't want a new window popping up for every person with whom they exchange private messages.
It does have the advantage of not returning the away message when you NOTICE a user who has set himself /away.
Another reason you see so many notices is that DALnet and, more recently, EFnet both support a special type of notice that gives you the option of sending a message only to the channel's operators and/or those who have a voice in a channel. This type of message displays to the recipients as a plain NOTICE. It is indistinguishable from a normal NOTICE unless the sender makes it clear it's gone only to ops by adding some text to that effect.
You can send a NOTICE to a channel, single user, or selected group, just as with private messages, but they appear different. Generally not used in personal communication, they appear in either your status window (for most Windows clients) or the main window, with the following format:
-Noticer- Thank you for joining us.
Note the hyphens (-) characteristic of notices. Most clients share this convention. mIRC users see them in their status window by default.
CTCP Requests
CTCP stands for Client-To-Client-Protocol and is a form of private message. Their display and handling depends very much on your client.
CTCP is a message requesting information in the form of an automatic response from your client.
Incoming CTCP requests in mIRC appear in red in your status window with the nickname of the sender and the keyword of the request in square brackets ([]). For ircll, a CTCP request states that it's CTCP, so as not to be confused with other kinds of messages.
11:27 [Freenode] [ctcp(TIME)] HARRYKAR
*** CTCP TIME from Timeless
[Timeless TIME]
This means a user with the nickname TimeLess sent a CTCP request to you with the keyword TIME. If your client doesn't recognize the CTCP command, it may tell you that it's received an unknown CTCP or ignore it altogether. Depending on the client, the target of a CTCP (a channel, your nickname, or a group of users) may display along with the CTCP request.
You should not respond to CTCP messages—after all, their point is to elicit an automatic reply.
DCC Requests
DCC requests are a form of CTCP, which in turn is a form of private message. DCC is a means of file transfer and private communication independent of the server or network(like P2P).
You see a message that you have received a DCC request and describing the type and source of the request. It also contains extra information your client will need if you accept the DCC request, but this does not normally display. The message could also take the form of a small window that opens and asks whether to accept or decline the request.
If you're not sure where the DCC request is coming from, refuse it. Especially if it's a DCC SEND request (a file offer), be wary, since the data received could present a security hazard to your client or machine.
Sending files meant to render the receiver vulnerable to attack or permit others to access the machine is an increasingly common method abusers use to gain control over someone's client or machine. Don't be afraid of offending someone by refusing a DCC SEND (or CHAT) offer.
Wallops
Whether these are common or rare depends on your network. There are two forms,
- one from IRC operators and
- the other from servers.
Regular users can't send wallops.
You will not receive any unless youhave user mode w set, and you don't really need it.
Typical forms of wallops are the following:
!Barron*! Behave or I'll jupe the lot of you
This means an operator with the nickname Barron sent the message as a wallop. The contents could be anything a normal message would contain. The asterisk indicates an operator rather than a server or regular user sent it (not that regular users are allowed to send wallops nowadays—it's really a redundancy)
!Hacker! Possible clones (8) from dialup-34.netabuse.com detected.
The above may be from an operator, but in some cases—as in this example—it originates from a service robot with the nickname Hacker, informing the network's operators of certain events or warning them of potential or actual abuse.
!ircd.nl.net! Remote CONNECT ircd.webbernet.net 5550 from delta
You will occasionally see this type of wallop if you have usermode w set. What's happening here is that server ircd.nl.net is informing the network that it received a CONNECT command from the operator whose nickname is at the end of the notice (delta) to attempt to connect to server ircd.webbernet.net on port 5550. This is a routing intervention the operator considers necessary in order to correct a network fault. A similar message appears if an operator orders a server to disconnect from another with the SQUIT command, and the operator's reason for breaking the connection follows. A server sends a wallops when the operator issuing the command is not connected to that server.
Operator Notices
Occasionally, if an operator thinks the server's users should be informed of something, he or she sends a private message or notice to all users on the server. This message looks identical to a normal private message or notice. Usually only the contents identify it as server-wide.
Some clients, though, recognize it as such and append the mask of the group of recipients to the operator's nick, thus making it clear that the message was directed at all users of a server. Do not reply to operator notices unless they explicitly ask you to.
Operators sometimes use server-wide CTCPs or private messages to detect unauthorized bots, and replying to them could result in your being considered a bot and getting killed or K: lined.
Local Machine Messages and Talk Requests
On a Unix machine, a broadcast message from a user on the same machine or the machine's superuser (root) may interrupt you. There is a Unix command to forbid such messages from reaching you. Only messages from root override this setting and will always reach you. Messages from root usually concern machine downtimes or usage policy, and you should pay attention to them. To prevent messages from reaching you, add the command mesg n to your log-in file (.profile, .cshrc, or whichever you use). You can also use this command or its opposite (mesg y) from the command prompt or from within any client supporting a command such as ircII's EXEC.
Also, on Unix machines running a talk daemon, you can reach users from any machine on the net by using a talk client. Talk is a simple form of communication for one-on-one direct conversation. Abusers sometimes use talk to create havoc on a user's display with a program named flash. You can prevent this with the mesg n setting described above, but you will also be unavailable to any normal talk request.
A regular talk request appears in the bottom part of your main window saying there is an incoming talk request, and tells you what to type in order to respond and establish a talk connection. If you want to accept the talk, you have to quit ircll first or open a new screen or xterm, if you are able to. Flashes look like a lot of garbage telling you that you have a talk request from your own address, and parts of the screen start to blink. Set mesg n immediately without quitting and restore the screen with the CLEAR command or by pressing CTRL-L:
/exec mesg n
/clear
If you want to talk to the user who sent you a talk, you can send
/DCC TALK user@host
to the user and talk through the IRC window. To send messages to the talker once you've completed the talk handshake, type:
/msg @user
This applies only to ircll. Both EPIC and BitchX have removed this function; you will have to use the conventional way of opening a new terminal in order to reply (or quit IRC first if you cannot open additional terminals). Additionally, it conflicts with op notices used on DALnet and EFnet, where the target of a message can begin with an @. You'll probably be more interested in op notices, but in order to use them with ircll, you will write an alias to override the old function. Don't sweat over it yet.
Actions
You'll often see someone on a channel "doing" something. A leading star characterizes this action, followed by a third-person description of the user's action or an emotional state he or she would like to describe in this manner. You can also use actions in private messages, where they'll appear in a query window or with an asterisk-angle braket (*>) prefix to indicate the action is sent privately and not to the channel.
* harrykar np: Beppe Gambetta - Hunterdon Bolero (2:27 / 3:11)
A properly written action looks like a sentence with the sender's nick as the noun. A bad action is the sender's nick followed by something grammatically unsound or incoherent. That can also happen.
Server Notices
You shouldn't normally see a server notice unless you've asked to see some or all types of server notices by joining a channel or setting a user mode that makes the server send you such notices. They are intended to inform interested operators or users of events concerning the server or network.
Technically, they are a distinct class of message, and you can expect your client to treat them differently from regular notices when displaying them. In the beginning, you shouldn't encounter any at all—later, if you're interested in the way servers run.
I Joined a Channel and Nothing's Happening!
This is not an unusual occurrence. It could indicate some network, client, or other technical problem, but more often than not there's simply nothing to see. Even if there are 15 or 20 users on the channel, don't panic! Many people leave their client on a channel even while they're away; some of the idle clients may be bots. Joining a channel and meeting silence isn't all that odd, especially if you join a channel in the middle of the night or when everybody is (or should be) at school or at work. Don't expect the absentees to have set themselves away. Most of them will still show as here, largely because not many people pay attention to setting themselves away when they're not around.
Many people also use multiple channels and sometimes don't pay attention to the rest when they're talking to a particular channel. They could have the channel's window hidden when they're not following it and check on it periodically. You're not being scorned—in fact, very soon you'll find yourself doing the same thing.
Etiquette
There are no formal rules regarding the contents of your messages, but you should keep two rules in mind when talking to others on IRC or sharing a channel with them. I suggest you take these basics of etiquette (or "netiquette," as it is often referred to) to heart:
- Show others the same courtesy you expect them to show you.
- Use common sense.
Always remember that your messages are going out to people—humans with their own ideas, emotions, levels of tolerance, soft spots, and all those other psychological quirks that make the human animal so intriguing. As in real life, you probably won't be able to avoid the odd faux pas, and you might even be glad others can't see your face turning a deep beet-red color. This doesn't mean you have to be quiet and behave as if treading on eggshells. You can be conversational and active without offending people all the time.
Disagreements and the odd fight are a part of life, but insults aren't necessary.
Some other points you should remember in order to avoid be coming unpopular are the following:
- Don't repeat the same message over and over. If you mistype a message, don't correct and resend it. Leave it as is if the message is understandable, or send only the correction. A common way of correcting oneself is resending the mistyped word or phrase followed by the word even.
- Don't flood the channel by sending large text files.
- Excessive use of colored text and highlights is generally unwelcome.
- Barging into a channel and doing an "age/sex" check isn't generally appreciated.
- Using actions all the time looks silly.
- Advertising your channel or Web page usually gets you kicked out.
- Stay within the channel's topic of conversation.
- ASCII art may look smart, but few people really appreciate it. Sending too much of it will probably get you kicked out of a channel. Experimenting with ASCII art on a channel in the midst of a conversation isn't polite. Create a separate channel and test it there.
Ignoring Messages
You're bound to encounter someone who appears to have no sense of netiquette or politeness at one time or another. Some of these people react well if you tell them their conduct is inappropriate, but others don't. If you're an operator of the channel, you can silence the more obnoxious ones by kicking them out. If you're not, or if someone is pestering you with private messages, you can silence them with the IGNORE command—BBS veterans know this as "forgetting." The use of
IGNORE is very different from client to client.
IGNORE is a client function and niters received messages. On the other hand, the SILENCE command, available on DALnet, Undernet, and similar servers, has the advantage of reducing the load on your own client by letting the server do the dirty work. It instructs the server to block messages from the user(s) you want to ignore rather than sending them to you and letting your client sort out the mess.
Ignoring with ircll
You can use IGNORE with either a nickname or a host mask. In most cases, the nickname is enough. People who are more persistent in their attempt to annoy you can get past this kind of IGNORE by changing nicknames. Clients trying to get you disconnected through flooding are best ignored by their user@host mask right away. In an emergency, you can also ignore all messages by ignoring the address *@* and the message type ALL. The basic syntax of the command for ircll is:
/ignore
The message type can be one or more of the following:
- ALL Everything
- MSGS Only private messages
- CTCP Only CTCP messages
- NOTICES Only notices
- PUBLIC All public channel text
- WALLOPS Only wallops
- CRAP Odd stuff like nick changes, joins and parts, and so forth
- NONE Removes someone from the ignore list
You can specify multiple types with a space-separated list—for example:
/ignore Loser msgs notices ctcp
You can stop ignoring single types of messages or exclude them from ALL by preceding them with a hyphen:
/ignore Loser -notices
This would stop you from ignoring notices from the user with the nickname Loser, but would still keep msgs and CTCPs from the same user on ignore:
/ignore Loser all -public -crap
This would make you ignore everything except public messages and what falls in the CRAP category (that is, you'll still be able to see the user leave the channel). BitchX users should use nick!user@host format for the IGNORE rather than ircll's nick or user@host.
Ignoring with mIRC
The command, again, is IGNORE. However, mIRC uses a different format for adding switches to include or exclude certain types of messages. It's also able to ignore a user's host mask by entering only the nickname in the IGNORE command.
/ignore [-switches] Nickname|nickluserghost [type]
If you want to ignore a user's address instead of just the nickname, you must use the full nick!user@host format, using asterisk (*) and question mark (?) wildcards where appropriate. The following switches are recognized:
- -c Public messages
- -i Invites
- -k Color in messages is ignored
- -n Notices
- -P Private messages
- -t CTCP messages
- -uN Will automatically remove the IGNORE after N seconds
- -r Removes the IGNORE from the nickname or host mask.
The type of IGNORE is optional. If you don't specify any, only the nickname is used. If you use one of the following numbers, mIRC ignores more than just the nickname:
- 0 *!user@host.domain
- 1 *!*user@host.domain
- 2 *!*@host.domain
- 3 *!*user@*. domain
- 4 *!*@*.domain
- 5 nick!*user@host.domain
- 6 nick!*user@host.domain
- 7 nick!*@host.domain
- 8 nick!*user@*.domain
- 9 nick j*@*. domain
Note that using a type makes mIRC query the server for the user@host matching the nickname. Under conditions of lag or during a serious flood, this is probably to your disadvantage—it would be more efficient to manually enter the mask you want to ignore.
The SILENCE Command
This command is available on Undernet and DALnet servers. It sets a server-side ignore—that is, messages from the address or user you want to ignore never reach you; the server blocks them. Not all clients directly support the SILENCE command—you might have to use RAW or QUOTE in order to send it; otherwise SILENCE will do just fine.
/quote silence +blah@blah.com
The plus (+) prefix activates a server silence while the hyphen (-) reverses it. DALnet and Undernet servers both automatically convert user@host into nick!user@host. You cannot silence a nickname on DALnet—it must be a user@host. Using SILENCE with your nick as the only parameter, or using no parameter at all, displays the list of addresses you have silenced.
Sending to a Channel
Sending to a channel is the simplest form of communication. Anything you type that is not a command goes to your current channel or window. The contents of the message can be absolutely anything, though both the client and the server can restrict the message length.
Sending to a Channel While Not on It
You won't need to do this much, if ever, and it's more often than not ineffective.
Almost all channels are permanently set not to accept any messages from users who aren't actually present on them.
If you do want to do this, the command is MSG (which is actually a private message) with the channel's name as the recipient. This is because public and private messages are identical as far as the server is concerned, and the target can be a channel as well as a user.
/msg #Somewhere Hey! Let me in!
You can expect channel #somewhere not to accept messages from outside the channel, in which case the server returns the error message "Unable to send to channel."
Messages sent to channels from people who aren't on the channel can take a variety of forms. Unix clients generally present it like this:
/(Doe/#SomeWhere) Let me in!
Version 5.61 of mIRC, as well as earlier versions, make no visible distinction between a message from a user on the channel and one from outside. This is an omission I hope subsequent versions fix since it's confusing to see a phantom user not on the nickname list sending messages to a channel. This event can have various causes; either the channel does not have mode n set or you or the user sending the messages are desynced from the channel.
Communicating with Multiple Channels
If you've joined more than one channel and are taking part in the conversation on all of them, you'll need a means of directing each message to the right channel. While you can do this easily on clients that have a separate window for each channel—you just switch to the window required—there are also other ways of doing it.
One way is using the MSG command In this case you will be on the channel even if it isn't your current channel (the current channel concerns only the client—as far as the server goes, you're just present) so the server accepts the message and sends it to the channel. If you're using ircll, you've already seen how to switch between channels —this is more convenient than using MSG—just switch to the channel you wish to use and send a public message as you would normally.
Sometimes you want to send a message to all the channels you're on—for instance, to say you'll be away for a few minutes. The MSG command can take multiple recipients in a comma-separated list:
/msg #somewhere,#otherchannel Away for a few, don't go away!
Both channels receive an identical message regardless of which is your current one. The AMSG command simplifies this procedure in mIRC:
/amsg Away for a few, don't go away!
On servers running EFnet's 2.8.21/hybrid-6 version, you may no longer use multiple targets for any type of message.
Sending Private Messages
Private messaging is the primary use of the MSG command.
/msg nickname shhhh... they can't hear us!
And indeed, they can't. Try sending yourself a MSG and seeing what it looks like on both ends. You can also use MSG for sending a private message to multiple recipients with a comma-separated list, as for multiple channels.
Using QUERY
QUERY is a client command to facilitate sending private messages without having to use the MSG command for each message.
Clients have replaced this command by opening a new window for each private communication, but the change has led to confusion regarding the term query. Simply sending a user a private message is not a query. Using a dedicated window for sending messages to a user without having to use MSG for each message is a query. I think the name of the command was a rather unfortunate choice by the authors of early clients since the word doesn't reflect the function performed.
For ircll, QUERY works simply like this(The target can be a nickname or channel
):
/query target
To close a query, just type:
/query
while in the query window. If you're using mIRC or another graphical client, simply close the query window belonging to the user with whom you've ceased
corresponding.
Strange Characters in Messages
Sometimes you'll notice unusual characters appearing on your screen or people saying things that can't possibly be in a human language. Depending on the kind of characters you're seeing, there are different explanations.
If seemingly random strings of characters are reeling across the screen, you are either being flooded or, if you're connected to your host via a simple terminal, line noise is affecting your modem. Sequences of text with many dollar sign ($), B, and square bracket ([) characters or word-size strings made up largely of vowels are likely to be non-English channels. If a user spouts a stream of gibberish and then signs off, chances are he or she fell victim to line noise and lost the modem connection. You can expect single unusual characters to be part of a foreign Latin-based character set such as Swedish, Finnish, or Portuguese, as occurs in channel names.
Colored Text and Highlights
Some clients are capable of sending and reading bold, inverse, underlined, or colored text by adding certain control characters to a message.
While these can add to the effect of a message, they are client specific, and clients of a different type than the sender's may not support them, resulting in garbage on the receiver's screen. You should avoid them unless you're really certain they're appropriate. The IRC community generally frowns upon excessive use of highlights and color, especially if you're sharing a channel with users whose clients don't support these elements.
Different clients use different control codes for the same highlights; don't ask me why. When mIRC introduced highlights and color in version 4.7, for no apparent reason it diverged from the standard set by ircll (the first client to support highlights), and other clients followed it. The result is a double set of standards—you can expect clients other than ircll and mIRC to follow either one.
Regarding color, clients almost universally follow mIRC. This color is not real ANSI color—it is exclusive to the IRC clients that support it.
Using Highlights with ircll
Bold, inverse, and underlined text are all supported by ircll. More recent Unix clients based on ircll are also capable of reading ANSI and mIRC color—ircll requires extra scripting to display or filter out color-related codes. Certain control characters surround highlighted text, depending on the type of highlight. These characters are (the ^ character means that you press the CTRL key along with the letter or underscore) :
- ^B Bold
- ^V Inverse might require you to press ^V twice before the character appears, both at the beginning and at the end of the text, to highlight it.
- ^_ Underlined
When adding highlights to a message, the relevant characters appear in inverse on the command line as you type them. While underscore almost never fails, bold and inverse might need some extra attention with some systems and clients. Inverse Bold sometimes requires a new key binding if ^B is bound to a different function.
/bind ^B self_insert
The SELF_NSERT function inserts the actual control character in the text with the key press, rather than performing a function assigned to it. Add that line to your .ircrc file. You'll rarely need it for the other highlights. Remember to close the highlight by also adding the appropriate control character at the end. You can combine any of these highlights by enclosing the text to highlight between more than one pair of control characters (making sure the pairs close in the reverse order of their opening). Some types of highlights or combinations might fail to appear on some terminals.
As of version 4.4H, ircll supports mIRC-style color. You can turn its display on or off with SET COLOR ON/OFF—the compile default is off. To use color, follow the guide in the next section, replacing the ^K key with ^C (you will need to bind it to SELF_NSERT as with ^B above).
Using Highlights and Color with mIRC
The mIRC client recognizes color, bold, inverse, and underline, providing you're using version 4.7 or later. On older versions, the corresponding control codes appear as blocks instead. For bold, inverse, and underline, mIRC follows the same conventions as the ircll client, although the actual keys you use to produce highlights are different. To send highlighted text with mIRC, enclose the text within a pair of the following control characters (the caret ( A ) means you press the CTRL key together with the letter):
- ^B Bold
- ^R Inverse
- ^U Underline
You can insert plain text in fully highlighted sentences with ^O.
Color is a bit more complicated. You create color codes with the ^K key press, followed by a number indicating the color, and optionally a comma and another number denoting the background color. You should leave no spaces between the codes and the text or between CTRL-K and the codes. After pressing CTRL-K, you see a black block, after which you enter the numbers.
Examples:
- ^K 5 Brown text on the default background
- ^K 15,1 Light grey text on a black background
- ^K 0,0 White on white
Some people use it to exchange pseudo-invisible messages. Anyone not displaying color can still see the message. You can use color in almost any text, including channel names, channel topics, your real name, quit messages, and private messages.
You can't use it in your nickname. You can technically use color in your user name, but this is highly irregular and considered very lame—most servers deny you access if you have control codes in your user name.
Smile!
Smileys are all those funny character strings such as :-) that sometimes follow messages. They are meant to convey a facial expression. Many are widely used and universally understood, while only some users or channels recognize others. Still, you can usually guess their meaning by looking at them. With a bit of imagination you can also create your own. If you can't immediately see the analogy to a facial expression, hold the page sideways and look again.
Actions
Actions are easy to use and add much in terms of expressing oneself. Excessive use of actions, however, looks amateurish, and you should use them only when appropriate.
You perform an action via the ME command, which is a client function almost universal to all clients.
For example:
/me hides behind the couch
Technically, the ME command is a form of CTCP. This is important to know for scripting. You can also send an action as a private message with the DESCRIBE command or by performing the action with ME in a query window. Actions don't work within a DCC chat.
An additional mIRC command lets you send the same action to all channels you're on:
//ame will be back soon
Common Abbreviation
You'll often see some messages that look like secret codes people are exchanging to hide things from you. These are actually acronyms or abbreviations for commonly used messages, and each has a definite meaning. Some people also prefer to use these in lieu of bad language.
Autogreets
After you've received an autogreet, usually in the form of a notice, after joining a channel, you might want to use one yourself. This would require a bit of scripting (with ON JOIN). Autogreets, while increasingly common, aren't really liked because once the first impression wears off, they look fake and insincere.
Using autogreets can also generate a lot of unnecessary traffic following netjoins
apart from the more obvious annoyance of greeting the same people again and again. A genuine, typed greeting is much more welcome.
Keeping Track of Events by Logging
Many clients allow you to keep a log of events and messages by writing them to a file as they appear, from which you can retrieve and read them later.
Logging is a client function.
Logging with ircll
IrcII has two variables for logging that will tell it when to log and which file to log to. Set the LOGFILE variable to the file name you're using, and set LOG on to start logging and off to stop. If you're using multiple windows, you can log them separately with WINDOW LOG, and the client appends the name of the channel or query to the file name for identification.
/set logfile ire.log
/set log on
Or change to the appropriate window and type:
/window log on
If you use /set log instead of /window log while using multiple windows, everything from all windows ends up in the same file.
If a logfile already exists when you start logging, the new messages are appended to it.
Logging with mIRC
To do this, simply click the box in the top left corner of the window containing the contents you want to log, then click Logging. A checkmark appears next to Logging. Do exactly the same thing to cease logging. Alternatively, you can use the LOG command
/log on
/log off
from within the window you want to log. Under the File menu, select Options • IRC • Logging to configure the way it logs items, and specify the directory where the logfiles are kept.
Communication Problems
You might sometimes encounter strange problems when trying to communicate with a user or channel. While bad network connections or channel settings often cause these, some are also client-side problems.
Can't Send to Channel
Either you're trying to send to a channel that doesn't permit messages from outside while you're not on it, or you're trying to send to a moderated channel without having a voice. If you're getting this message even though your text is appearing normally on the channel, the cause could be desync. Note that your client makes the message appear after you've sent it—the client doesn't receive the message from the server. This means you'll see the message in the channel's window even if the server rejects it. To be sure a message has been received by the other user (s), you'll have to wait for a response from one of the other users on the channel.
Text Is Scrolling on a Single Line
This problem is unique to Unix and ircll clients. Try changing your terminal settings—vtlOO is the terminal emulation you should be using. Having it set to ANSI often causes this particular problem. After changing the terminal emulation, log out and log in again. If that fails to correct the problem, try this:
/set scroll off
/set scroll lines 1
/set scroll on
If you're really unlucky, you have a "dumb" terminal and will have to make do with having the new text overwrite the old once the screen is full. These terminals are increasingly rare, though.
I Can't See My Nickname before My Messages
This is entirely client dependent, and easy to fix. Some clients do show your nickname by default, while others do not. For mIRC, follow these steps:
- Go to File • Options • IRC.
- Check Prefix own messages.
For ircll, add the following line to your .ircrc:
- ON sendjnsg "*" echo <$N> $1-
This concerns only public messages—you don't need to change anything for other kinds of messages.
FINDING PEOPLE ON IRC
Be forewarned that IRC servers respect their users' privacy, and if people don't want to be found, they can't be. They can sit on a server outside all channels and not exist as far as nearly everyone else is concerned—with the exception of IRC operators.
WHOIS
If you already know a user's nickname, you can use the WHOIS command to see the information the server has about that nickname.
WHOIS works whether a user is invisible or not. It also shows you any public channels this user is on, except secret channels.
You can also use WHOIS to check a user's idle time by requesting the whois information from that user's server.
/whois server nickname
You can substitute the nickname for the server, as with other commands:
/whois nickname nickname
Many people have found it convenient to write an alias for this "double whois," and it's also present in most reasonable scripts (often with the alias "WII"). This form of WHOIS requests the whois information from the user's server (or any other server, but servers other than the one that user is on will normally show no more than yours does). You can also use it as a diagnostic tool for detecting desync by comparing a user's whois information as different servers see it.
If you have a rough guess of the nickname you're looking for, WHOIS supports wildcards on most servers. Wildcards (to introduce something you'll encounter a lot further down) are special characters that substitute for others, as follows:
- A question mark (?) stands for any single character except no character.
- An asterisk (*) stands for any number of any characters, including none.
WHOWAS
WHOWAS helps you when the user you're looking for is no longer online or has changed his nickname while out of your sight. You can use WHOWAS to find out the last instance the server saw a nickname, and quite often also the last few times. Unfortunately, WHOWAS information doesn't last long. Exactly how long the server stores information about the past use of nicknames depends on its setup and the nickname turnover (meaning the total instances of nicknames used and retired again).
A large network during high-traffic hours may store WHOWAS information for no more than half a minute. On networks with little traffic, it may last more than a day.
WHOWAS works only with nicknames. There is no way of using this command to detect the last time a user from a particular address was on.
Actually, you'd use WHOWAS to obtain the last address from which a nickname was seen. It returns any away message the user had at the time of quitting or changing nicknames, but none of the channels he was using.
WHO
In many cases you won't know what nickname the user you wish to locate is using. This is where the WHO command is useful. You must have some other information about this user in order to use WHO. Let's say you remember that the user hangs out on some channel that has the word ball somewhere in its name.
Note that WHO never returns information about invisible users (those who have user mode +i set).
So if your friend is invisible, WHO is of no use to you. More and more users on the large networks are now invisible, either because they set themselves as +i or because the server to which they 're connected sets all users as +i by default. The percentage of invisible users on the major networks ranges from about 50 percent on DALnet to over 85 percent on EFnet. Much of this desire for privacy is due to the immense number of pornography-advertising spam hots messaging all visible users and forcing them to use +i to avoid those messages.
/who *ball*
This will return a number of irrelevant things, since WHO will show you any visible user with the string ball in the user name, host name, nickname, server name, or real name. If you aren't careful to use a string that matches a large server as well, you'll get a lot more than you bargained for. Try to be as specific as possible. Wildcards in a channel name will not work—you must use the full name of the channel, including the prefix (pound sign, plus sign, or ampersand).
If a channel is secret, WHO will tell you nothing about its users, and the command fails to return any information at all, whether your friend is visible or not. You'll be a lot better off using a part of the user's address, as much as you remember, but allowing for dynamic addressing.
For example, if you recall the user's host mask as nick@dialupll.nyc.whatever.net or you get that address using WHOWAS (see below), the dialupll part is obviously dynamic and therefore should be wildcarded since your user may have dialed in again and been assigned a different address. So you can use the rest, which consists of a geographical identifier and the domain name. Not all providers use such identifiers—you might have to use just the domain name.
/who *.nyc.whatever.net
If there are any users matching that mask and not invisible, you will receive their WHO information. This is the most common way of using WHO.
WHO scans the channel name, nickname, real name, user name, host name, and server name for any string you specify. It's important to remember that it treats the user name and host name as separate parts, and your client adds the at (@) character you see between them, so you shouldn't use that character in a WHO query.
If you're lucky and have a client that supports flags for WHO, you can select which parts of the WHO output to search for the string. It's very useful to limit the list, especially if the string you're searching for is likely to return many irrelevant entries. Here are the flags ircll uses (which other clients supporting flags should also use):
Flag Type of Result
- -name User name
- -nick Nickname
- -oper IRC operators only
- -chops Channel operators only
- -host Host name
- -server Server name only
For example, to find your friend whose host mask is nick@dialupll.nyc.whatever.net with the user name flag, you would type:
/who -name *nick*
and the results will be only those with the string nick in their user names. The mIRC client does not support WHO flags, so the above is irrelevant for that client(i don't know about the last releases). The same applies to many other clients.
NOTIFY and ISON
Many clients allow you to maintain a list of nicknames of which you wish to be notified if they join or leave IRC. How you set up such a notify list varies from client to client, but the way it works is identical. If there is a notify list, your client periodically sends ISON commands to the server, asking it whether the nicknames on the client's notify list are present. The server replies with the nicknames present. Your client compares the reply to its internal list of nicknames present (as the last ISON saw them) and notifies you of changes to the list, telling you which nicknames it has detected that were previously absent and which ones are no longer there.
NOTIFY works on nicknames only. You can't use it for addresses or host masks (this used to be possible with NOTE, a practically obsolete command very few servers now support). Since anyone could use the nickname you have on your list, you should check the host mask of the nickname, either with WHOIS or by scripting a line that checks it with USERHOST.
You can also use ISON independently of NOTIFY:
/ison nickl nick2 nicks ...
The reply might look somewhat like this:
*** Currently online: nickl nicks
The server's reply mentions only the nicknames that are present—it will not tell you whether this or that other nickname is signed on. That's the task of your client's notify system.
Note that NOTIFY is a client function, while ISON is a server command. Some clients (notably ircll, which added an ISON command only in recent versions) don't support ISON as a user command, so you'll have to send it as a raw server command, using the RAW or QUOTE command.
NAMES
NAMES is actually of little use in rinding users, but you can use it for a rough check of a channel's users. Again, as with WHO, unless you're on the channel yourself, invisible users and users on secret channels will not appear.
WARNING
Do not use the NAMES command with no parameter—it will return all visible users on the network and place an unnecessary load on your connection, possibly also resulting in the server's disconnecting you. You may safely use it on networks with a small number of users. However, if you try it on a major network you'll recoil in shock and stare at the scrolling screen in honor. This is not a newbie error. Everyone does it by mistake every once in a while, including yours truly.
And, yes, I hate it when that happens! If it happens to you, type
/flush
to chary our buffer. You may, although it's rare, lose a message someone just sent you if you do this. Generally speaking, it's worth it. But if a conversation you were having suddenly ends, it might be because that person is waiting for you to answer a lost message. Usually just saying, "Did you say something to me? I missed it, " will put you back in the messager's good graces.
Finding the Operators of a Channel
You'll sometimes want to find a channel's operators in order to receive the channel's key or ask to be unbanned or invited. For this, you can use both the WHO and NAMES commands, again with the limitations of secret channels and invisible users. If your client supports a flag allowing you to list only channel operators, use it.
If a channel is closed with a password (key) or requires an invitation
(invite-only), chances are its occupants do not wish to be disturbed. Consequentially, the channel will most likely also be secret, and all attempts to see its users from outside will fail. It's really best to take the hint and go to another channel.
Network Services
If the user you're looking for has a registered nickname on a network that provides a nickname service (usually called NickServ), you can try requesting information about that nickname from the service. More often than not, it will say when it last saw the owner of the nickname using it and at what address. A common syntax for querying a service about a nickname would be:
/msg info
but this may vary from service to service. Send the service a help message if you're in doubt. If the same network also has a memo or note server, usually under the predictable name of MemoServ or NoteServ, you could also use this to leave a note for that person.
Here's a sample output of an information query on DALnet:
NickServ- *** LART is Web Net IRC
NickServ- (Currently on IRC) For extra info /whois LART
NickServ- Last seen address: apatrix@ircd.webbernet.net
NickServ- Last seen time: Thu 01/07/99 06:58:50 GMT
NickServ- Time registered: Wed 04/08/98 15:49:44 GMT
NickServ- Time now: Thu 01/07/99 06:59:06 GMT
NickServ- This user will not receive memos
NickServ- *** End of Info ***
This information says that the nickname LART is currently in use and gives the address of the person using it. The second line would be missing, were he not on DALnet at the time. Depending on the user's preferences, there may be additional lines containing information about those preferences. Note that unlike the vast majority of users, this unsociable individual will not accept memos, so you couldn't use DALnet's MemoServ to send him a note.
Finger
The finger command is strictly for users on machines with a finger daemon—basically meaning multiuser Unix machines. It is not an IRC command, but a separate protocol. Some clients are capable of sending a real finger query (as opposed to CTCPfinger, which, being CTCP, queries an IRC client and displaying
the reply. This is another confusing ambiguity of command names, but we must remember that commands such as finger, ping, who, and whois actually predate IRC and gave their names to those IRC commands with similar functions.
If you know the other person's user name on the system, finger the whole address, as in george@my.provider.com. This does not necessarily match the user's email address, since the email address often contains only the domain, while finger must target the user's host.
You must direct finger at a specific machine. If you don't remember the user name, try requesting a list of all users logged into the machine. Do this by fingering @host.name—for example, finger @my.provider.com. Many systems demand that you give a user name in a finger query, and refuse to give you this information. Most ISPs refuse to respond to finger queries altogether.
If you do get a reply, the amount of information returned varies depending on the finger daemon's setup, but often says when the user last logged into the machine or whether he is currently on. Even if the user is logged into the machine, it doesn't necessarily mean he is using IRC at the moment. He could be anywhere or nowhere on the Internet. Consider sending a talk request or an email.
Finding Someone's Location
Finding out where a user is located is often as simple as using the Unix command whois. Whois is the nominal ancestor of the IRC command with the same name, and is a separate protocol requiring a client in order to query a whois server about a domain or IP address. The relevant technical document is RFC 954, for those who care about Internet esoterica. In many cases you'll be able to deduce a person's location from the host mask if this includes a geographic identifier or has a characteristic country code. Often, though, especially with North American sites, this is inconclusive, and you'll want additional information. Use a regular finger client or a special whois client (available from good software sites) to ask a whois server where the user's domain is registered. More often than not, the user's whereabouts are in the same city or close to the place where the domain is registered. You can also use whois to check where an IP address is registered.
The three main whois servers contain the data for the three primary zones:
- whois.ripe.net (Europe, Middle East)
- whois.arin.netandwhois.internic.net (America)
- whois.apnic.net (Asia, Pacific)
They also have a Web interface if you lack a client to perform the query. Naturally, nothing is simpler than asking the other person. Most people will tell you where they are with no fuss whatsoever.
How Not to Be Found
- First of all, you should know that you are visible under all circumstances to anyone with whom you share a channel. There is no way around that.
- You're also visible to all operators of the server you're using—on some networks, operators of other servers can also see you regardless of your status. There is no avoiding this either. You can hide from everyone else. Note that it's considered highly unethical for server operators to divulge information to a regular user if that user would be unable to obtain it on his own. So don't worry—you can rely on their discretion.
- If you're on no channel at all, simply setting yourself as +i does the trick.
- If you've locked yourself into a secret channel, chances are you're pretty safe from detection there as well.
- It's a bit more tricky if you're sitting in a large public channel. Anyone may join it and find you there, including people who suspect you might be there. The same goes for any channel you're known to frequent.
- If you really want to keep nosy parkers from finding you on such a channel, you'll have no choice but to ban them. Naturally, this would require channel operator status.
- If you're really paranoid about being found, you may end up having to leave the channel.
CTCP
Now we'll be getting a bit more technical. You don't absolutely need to
know all the techie stuff in this section but you'll be lost without knowledge of
the basic CTCP command set. If there's something you don't understand ("What the heck's a PRIVMSG?"), don't freak out over it. Read on
CTCP Explained
CTCP stands for Client To Client Protocol and describes a set of commands a client responds to automatically. The basic command set is part of the client, and every advanced client permits user-defined CTCP commands and often has additional commands particular to that client. To the server, CTCP is no different from MSG, since technically the two are the same type of message, for which the server command is PRIVMSG.
We saw earlier the difference between the commands you send your client and those the client sends the server. The server's limited command set isn't enough to provide for all the users' wishes and needs—indeed, it doesn't have to. Therefore, several commands you use will actually translate into the same server command.
Only the client distinguishes between a normal MSG and a CTCP message, so it's the message contents that allow the client to recognize it as a CTCP command.
The defining characteristic is a CTRL-A (symbolized by ^A) character at the beginning and end of the message. When receiving a message that begins and ends with ^A, a client sees that message as CTCP and acts accordingly. This is not part of the IRC protocol, but a convention client authors added later. When they introduced automation (because they thought it would be cool, not because there was a dire need for it), they had to use some convention, since the only option for sending messages from one client to another on the server level was the PRTVMSG command, and there were no plans to expand the server's command set just to accommodate that.
Besides, supporting CTCP on the server level would be a contradiction in terms. Therefore they settled for a signal inside the message itself, which another client would interpret as a command.
Sending CTCP Requests
The normal way of sending a CTCP query is with the CTCP command:
/ctcp target command [parameters]
For example:
/ctcp Doe ping
Many clients and scripts support simpler forms of these commands, such as /version and /ping for /ctcp version and /ctcp ping, respectively.
Some, such as mIRC, allow you to use the CTCP command set from within a pop-up menu when you right-click a nickname.
Since the server doesn't see this type of message as different from a normal message, the sender can direct it at the same targets as those, including multiple targets. In order to elicit a response from the target client, the CTCP command must match one the receiver supports and include parameters it may require for a response. If the command fails to do this, the client receiving the faulty CTCP either returns an error response (CTCP ERRMSG) or ignores it completely.
Replying to CTCP Requests
To put it simply, you do not reply. You either make your client ignore all
or certain kinds of CTCP requests, or you let it reply automatically.
There's no reason to respond manually to CTCP—the whole point of it
is to provide an automated process of exchanging information.
CTCP Commands
The set of CTCP commands a client recognizes varies widely from client to client, but almost every client supports the basic ones. For explanatory purposes, the client sending the initial CTCP request is the "sender," and the one to which it's sent, and which reacts to it, is the "receiver." This is the basic scheme as it would appear on an mIRC client in the status window:
You send: /ctcp Doe version
Joe sees: [George VERSION]
That's all Joe sees. His client replies automatically, unseen to him.
You see: [VERSION reply from Doe: mIRC32 v5.51 K.Mardam-Bey]
When a CTCP reply gets sent, the roles actually reverse, but to simplify matters we'll continue to call the client that started the CTCP sequence the sender. Let's have a look at the principal CTCP commands. In this example, both sides are using mIRC and the messages appear in their status window. The way CTCP messages display varies wildly from client to client. mIRC (and I consider this a disadvantage) by default does not tell you if the CTCP is directed at you personally or at a group of users, as is the case when someone CTCPs a channel or an operator CTCPs an entire server's users. If you want to see the target of
the CTCP displayed, you have to script it yourself.
ircIl users must have a client variable set in order to see the CTCP message they're receiving. If you know you 're being sent a CTCP, you 're sure you 're not ignoring the sender (or all CTCPs), and you still can't see them, you need to issue the following command:
/set verbose_ctcp on
I suggest adding this to your .ircrc file if you didn't setup the client yourself. Having verbose_ctep set off does not affect your ability to return CTCP replies.
PING
The most widely used CTCP command is PING. The sending client generates a time stamp and the receiver bounces it back to the sending client (without adding a time stamp), which compares the reply to the current time. The sender then calculates the difference between the time stamp and the time it received a reply; the result is the round-trip time of the message.
CTCP PING is the user's main diagnostic tool for detecting lag.
All clients will (or should) return the PENG unmodified. If the response time is a ridiculous number like 920693456 or -14328, the sender or the receiver has a bug in handling CTCP PING, or the receiver is running a buggy script that causes it to return a new time stamp or none at all instead of bouncing back the time stamp it
received.
You'll sometimes see people asking you to Ping them. They want you to send them a CTCP PING and tell them the result so they can see if they're lagged. Why they would ask someone else to Ping them when it's much easier to send a PING themselves is a mystery, but probably stems from the misconception that people don't like to be Pinged. They may want times from more than one person, which they can easily achieve by Pinging a channel instead of a single user. This provides a wider sample of replies and more-accurate individual results. Your options are to ignore them, humor them, or enlighten them.
Obviously, when someone asks you to Ping him or her, it involves the exchange of four messages:
- one asking you to Ping,
- your Ping,
- their receipt of the reply to your Ping, and
- your message telling them the result.
If while using an ircll client you observe that all Ping replies, even the noticeably
delayed ones, return a time of 0, add the following line to your .ircrc (the problem
in this case is that the client isn 't sending out a time stamp):
ALIAS PING //ctcp $0- ping $time()
This alias also allows you to use /ping instead of /ctcp nickname ping. $time()
is a function which expands to the current time.
VERSION
VERSION is another widely used CTCP command. It sends a VERSION request; the response should be the type of client the other user is running. If the other user has some kind of script loaded, VERSION may return only the name of the script, from which with a little experience you can deduce the type of client. CTCP VERSION takes no parameters.
Nothing on IRC is faked as much as CTCP VERSION replies.
While many users regard CTCP VERSION as suspicious ("What business of yours is my client's version?") and some constantly IGNORE it, others simple fake the reply with a bit of scripting. Bots sitting on servers that don't welcome them are especially likely to return a fake reply in their attempt to escape detection by a server's operators. On most clients, you can do this with ON RAW_IRC, ON RAW, or the equivalent. ON CTCP, which many clients support, may not succeed with clients like ircll, which will not allow ON CTCP to suppress the default CTCP reply.
Servers generally expect all clients to respond to a CTCP request from an operator, so faking it or ignoring CTCP altogether is not necessarily a good idea.
mIRC users should not try to script out the client's version reply. You can ignore it or respond, but do not fake it.
FINGER
The FINGER command isn't used too often these days since many people regard it as snooping, especially if a total stranger uses it. While many choose to configure their client not to respond to it at all, others who haven't done so still may react nastily to receiving an unsolicited CTCP FINGER. The response would normally include one or more of the following data:
- the user's name,
- email address, and i
- dle time.
Whypeople who don't wish to be fingered allow this command is not clear—
probably for the same reason some people leave their curtains open and
then complain about lack of privacy.
TIME
The queried client replies to this command with the current date and time of the machine on which it is running. The accuracy of the reply depends, of course, on whether the machine queried has the correct time and time zone set.
ACTION
CTCP ACTION is what the ME command really sends. This is why actions don't get treated as public messages even if they're sent to a channel. Clients tend to treat CTCP ACTION as a separate type of event rather than an ordinary CTCP or public or private message.
Technically, they're just another PRIVMSG and just another CTCP. This is something you should bear in mind when scripting, especially if you're handling raw IRC. Most client scripting languages distinguish between an action and other CTCPs, but you can work around this distinction with raw IRC.
ECHO
An almost obsolete CTCP command, this simply bounces back the contents of the message. Some clients, including mIRC, no longer support it since it's of little practical use and CTCP flood attacks often utilized it You can safely ignore it.
CLIENTINFO
A useful command, CTCP CLIENTINFO returns a list of CTCP commands to which the client will respond. You can add the name of such commands as a parameter in order to obtain more instructions on using that command. This command can retrieve information about using a client's automated features; most "live" users (as opposed to bots) don't really appreciate it.
A typical CLIENTINFO reply might look like this:
*** CTCP CLIENTINFO reply -from JackSprat: SED UTC ACTION DCC CDCC
BDCC XDCC VERSION CLIENTINFO USERINFO ERRMSG FINGER TIME PING ECHO.
INVITE WHOAMI OP OPS UNBAN XLINK XMIT UPTIME
:Use CLIENTINFO command to get more specific information
This is characteristic of a BitchX client; both ircll and mIRC will return more limited command sets since neither one employs as much built-in automation as BitchX. The number and type of commands may vary greatly from client to client.
USERINFO
This command retrieves some personal information a user wishes known. Exactly what kind and how much information is entirely up to the user. Most clients, including mIRC and ircll, return no information by default, and most users don't care to add any. It is one more CTCP command that has largely fallen into disuse.
If you wish to allow people to see something when they ask for information with this command, ircll-based clients let you set the text you return by simply setting the USER_INFORMATION client variable. With mIRC it isn't so simple—you'll have to write an ON CTCP line in your remote if you want to return anything but a blank message. Also, the default pop-ups don't include it, so you cannot use it by right-clicking a nickname unless you edit the pop-ups file and add it yourself.
Common Client-Specific CTCP Commands
SOUND is used by mIRC and other clients that support sound. The parameter is the file name of the sound the receiver is to play. This requires that the receiver have the sound file on the machine and accessible to mIRC.
Scripts that react to certain events while a user is not present sometimes include PAGE, which "pages" the person by beeping, flashing the screen, or playing a sound file.
PRIVMSG and NOTICE
An important convention of the IRC protocol is that a client shall not respond to a
PRIVMSG with another PRIVMSG. This is necessary in order to avoid infinite PRIVMSG loops, which could occur if two clients were automatically responding to each other's PRTVMSGs. This little example demonstrates how two clients programmed to reply automatically to a PRIVMSG (in this case it's a public message, and it could also be a MSG or CTCP) with another PRTVMSG can go into an infinite loop:
StupidBot (bot@really.dumb.com) has joined channel #DumbBots
Hi there, StupidBot!
Hello, LameBot!
(They automatically greet each other. This is only the beginning. What
if they're not programmed to stop responding automatically to each
others' greetings?)
Hi there, StupidBot!
Hello, LameBot!
Hi there, StupidBot!
. . . Need I continue?
NOTICE, on the other hand, may not get an automatic reply at all, so it is practical and important that a client respond to PRIVMSG only with NOTICE. Since CTCP is a form of PRIVMSG, the same rule applies here:
A CTCP request is a PRIVMSG, while a response to a CTCP is a NOTICE.
As with the PRTVMSG, characteristically ^A characters enclose the message contents of the NOTICE sent in response to a CTCP query.
What we have now is the following:
You: PRIVMSG Doe : 0COMMAND parameters0
and the reply:
Doe: NOTICE George : 0COMMAND response0
These are the raw commands the respective clients send to the server.
Certain inferior clients and/or scripts do not add the trailing ^A character at the end of the CTCP message. Clients that allow for such "broken" formats may recognize this, but it looks bad on clients that require the correct syntax to recognize a message as a CTCP. These clients display a CTCP lacking the trailing ^A character as a regular message (public or private, depending on the target) starting with ^A. Really broken clients not only read such a malformed message as a CTCP, but may also respond to it.
Customizing CTCP Replies
Some clients allow you to define a custom reply to certain CTCP commands like FINGER or VERSION from the client's setup. For example, mIRC lets you change the finger reply with no trouble under FUe •Options • IRC • Messages and requires no scripting whatsoever. Others require scripting in order to circumvent the client's default CTCP replies, while more basic ones don't support any of this. If your client lets you set the CTCP replies from a setup menu, disregard the instructions below. When customizing your CTCP replies through a script with
raw IRC—if you care to, that is—remember the following rules:
- CTCP replies must begin and end with ^A characters. You must place the leading ^A before the CTCP command and the final ^A following the last parameter. The sender regards any part of the message not enclosed in ^A, as a regular NOTICE.
- A CTCP reply must be a NOTICE and not a MSG or PRIVMSG. If it's a PRIVMSG, the receiver reads it as a CTCP request instead of a reply, and you may end up with a loop if the receiver has an equally protocol-breaking setup.
- The first word of the reply message should be the CTCP command word. If you don't suppress the default CTCP reply, your client will send your custom reply in addition to the standard reply rather than replace it.
- mIRC does not allow circumvention of the CTCP VERSION reply. The only way to do this is to use modified versions (hacks) of the client, but these involve unauthorized modifications to the software and I do not recommend using them.
- CTCP PING should draw its parameter—the time stamp—from the sender's CTCP request and return it unmodified.
DCC
DCC (Direct Client Connection) is present in most modern clients and allows clients to communicate directly with each other outside the IRC network. What this means is that you can arrange a connection between your machine and someone else's with your IRC client, a connection that will function independently of the IRC servers and network.
No more scrambling for a new server when yours kicks the virtual bucket, no more messing with email attachments to send a friend on IRC your picture.
- Because DCC is initiated through a form of CTCP, DCC requires that both clients be on IRC and visible to each other (on the same network) in order for the initial request, which one of the clients sends, to reach the second client.
- After the second client has received the DCC request, regardless of whether or not the DCC connection is established it's of no importance whether the clients can see each other—in fact, if both got disconnected from the IRC network, the DCC request would remain valid.
- The way DCC is initiated and an established DCC connection is used depends entirely on the clients involved. All clients handle the basic types of DCC in a similar manner, although some newer clients have built-in extensions that others may not handle.
DCC Chat
Chat is probably the most widely used type of DCC. A DCC chat connection works similarly to a regular "talk" client, the difference being that it does not necessitate opening a separate screen, program, or terminal; you use it from within the IRC client program.
DCC chat allows a one-on-one connection with a higher level of security than communications over the IRC server network. Independent chat rooms (as opposed to channels) running on special clients or egg-drop bots also use DCC chat. These rooms are useful for bypassing server lag or communicating with people on different networks through a network of such clients.
Initiating a DCC Chat
All clients capable of handling DCC, graphical or not, should support the following syntax:
/dec chat
In addition, graphical clients may also have two more means of requesting DCC CHAT. The first is a DCC menu from which the user can select the type of DCC and the destination. The second is selecting a nickname from the channel's nickname list (that is, right-clicking on it in mIRC) and choosing DCC from a pop-up menu.
Accepting or Denying a DCC CHAT Request
When you're the recipient of a DCC CHAT request, either you receive a notice in your main window (text clients) or a small window pops up asking you whether to accept. It's really up to you, but many people consider DCC CHAT to be a more intimate form of communication.
I think it's a bit like kissing a stranger. When accepting an unsolicited DCC CHAT request, you're allowing someone you don't know to connect to your machine. That is (as I've said more than once), not a good idea.
On ircll and related clients, use the following commands:
/dec chat nickname
to accept, and
/dec close chat nickname
to reject.
Ircll keeps the pending request forever unless you use DCC CLOSE. Fancier clients such as BitchX and mIRC automatically time it out after a while.
Communicating over a DCC CHAT Connection
This is another form of communication that depends on the client you're using. Graphical clients open a new window for each DCC session, while text-based clients set them apart by giving DCC messages a different appearance.
Using a graphical client like mIRC, all you do is type your messages in the DCC window, just as you'd do with a regular message (query) session.
Under ircll and similar clients, send your messages to the DCC connection by prefixing the nickname with an equal (=) sign, like this:
/msg =Doe We are now in DCC
If you also have the tabkey script loaded, you can use it with DCC as well. BitchX automatically adds a =nickname entry to your tabkey holder so that pressing TAB after establishing the connection brings up the =nickname without your having to receive a message first.
File Transfers via DCC
The other main use of DCC is for file transfers. With DCC, you can swap files with other users without ever having to go through the pain of installing FTP servers or other file transfer utilities. The only difference you might encounter is transfer speed, since you are often transferring files to or from a machine that offers a slow connection compared to major software download sites. There's no knowing until you try, though. So if you want to send someone a picture of yourself, or trade sound files, this is the most convenient way of doing it.
Offering a File via DCC
Regardless of the kind of client you have, the following syntax should work:
/dec send
If the file is in a directory other than your current one, you of course have to specify the path to the file. With mIRC, you can also offer multiple files at the same time by adding more file names to the command line.
Receiving an Offered File
With graphical clients like mIRC, this is generally as simple as clicking on Accept when you see the window offering you a file. Yes, it is possible to accept files automatically, but with all the viruses and Trojans around, you do not want to do this. In fact, I strongly advise you—in your best interest—to resist the temptation of convenience. I know I'm repeating myself, but this is important. If the same user offers you more than one file, you have to accept each offered file separately.
On ircll and similar clients, use the following command to accept a DCC SEND:
/dec get nickname [filename]
The file name is not necessary if there is only one offer.
Resuming Interrupted Transfers
What happens when you're transferring a huge file and for some reason you lose the connection? This annoyed IRC users for a long time until someone came up with a solution: DCC RESUME. It attempts to pick up where the lost transfer left off, so if you have 509,433 bytes of a file from a previous transfer, it starts transferring from 509,434 instead of making you start anew.
Not many clients support this command, but two of the more popular ones, mIRC and BitchX, include the option.
I still think FTP is a more stable means of transferring large files, but not everyone can put files on an FTP server and not everyone wants to run an FTP server on their machine, so DCC is a convenient way of swapping files, especially small ones.
In mIRC, you see a menu when an incoming file matches a file name you already have. This menu asks you whether to overwrite the old file, resume a previous transfer, or rename the incoming file and keep both
DCC RESUME on mIRC and other clients following its lead breaks the protocol and entails the risk of entering an infinite loop.
File Servers and XDCC
All major clients can accept and send out files automatically upon request. The first to offer this was ircll, which had a variety of scripts for the purpose. The name of the most popular script was XDCC, a term that stuck. Later on, mIRC came up with its fserve and BitchX invented CDCC, both of which do essentially the same task but are integrated into the client, unlike XDCC, which is just a script.
You must set up file servers very carefully to prevent users from accessing files they shouldn't. By running a file server, you are giving other people access to files on your machine.
There are numerous XDCC scripts around for ircll and EPIC, and it's not possible to evaluate them all. They range from very basic to moderately complex and should provide instructions inside the file.
It's a good idea to check the script for back doors, too, if you decide to use one of them.
mIRC has a basic setup that you can combine with scripting to fine-tune its performance and access. Remember that all files you transfer come out of your pocket in terms of bandwidth, so running an fserve on a dial-up isn't always a good idea.
I suggest you create a directory in your mIRC directory and copy the files to which you wish others to have access into that directory. Then, under File • Options • DCC • Fserve, enter the full path of that directory in the appropriate field. The defaults of ten simultaneous transfers and five per user in that menu is probably excessive—adjust them to something more conservative, as you don't want every bit of bandwidth sucked up serving files. Of course, if you have bandwidth to spare, there's no problem with leaving the defaults. You also have the option of sending a message to people when they connect to your fserve. To do this, write a text file and enter its name in the second field of the fserve setup menu. The full help menu for fserve is under Help • Contents • Other Features • File Server; all options are listed there. You can set all the parameters of an fserve session from the command line you use to serve a user.
Be sure not to serve from directories you do not want others to access—for example, serving C: is not a smart thing to do, since it would let them access any files they liked on your entire C: drive. The same help item contains the commands to use when accessing another user's mIRC file server.
Note that there is no standard way of requesting file server access from other people; it depends entirely on how the other person has configured the client. MIRC clients with that form of automation often respond to
!their_nickname
while XDCC and CDCC on Unix clients are more likely to respond to
/ctcp nickname XDCC (or CDCC) LIST
Once you're inside the file server, the standard set of commands described in the help file does the trick if it's an mlRC file server. If it's a file server on a Unix client (including
egg-drop bots), you can expect it to have a help menu or show you instructions when you connect.
mIRC and the Science of DCC
Getting DCC to work right is one of the most common problems mlRC users experience. What works on one machine and one connection fails on another. Fear not, there's a solution to (almost) everything. The mlRC team has evolved DCC into a science.
Can DCC GET but Not SEND or CHAT?
This is close to the top of the all-time frequently asked questions list. Say that you can get files perfectly well and accept chat sessions someone else initiates, when you try to send a file or start a chat session yourself, all you get is an eerie silence followed by a timeout. Rest assured, you're not alone in this predicament. Barring the possibility that the problem lies with the receiver, you need to tweak your setup. If you're behind a firewall, What to do? Follow these five simple steps:
- Disconnect from the server.
- Go to File • Options • Connect • Local Info.
- Clear the "Local host" and "IP address" fields.
- Check "On connect, always get local host" and "Lookup method: Server." In special cases, you might have to choose to "always get" the IP address and not the local host.
- Reconnect to the server and try again.
If you're using a proxy or
bouncer, this technique will not work, because the server sees the address of the machine you're connecting through and not the machine you're on. If the client is unable to get its local address, you have to enter it manually and keep Normal checked.
What's This DCC Server Thing?
The DCC server can make your mIRC client act like a genuine server for DCC connections. Other clients can connect to your machine if they have your IP address, rather than having to look for you on IRC first or connect to another network in order to initiate a DCC session. You'll find it under DCC • Options • Server. It listens on port 59 by default, which is not a problem unless you have a firewall blocking access to that port. In that case, check with your firewall administrator to see what other ports you can use.
You can make the server listen for any or all of the following three types: CHAT, SEND, and fserve. By default, the DCC server doesn't bother to resolve the address of an incoming connection, but that isn't a big deal. The question remains of how secure this service is, not so much because of the file transfers but because of potential DoS attacks on any open port. Some suspicions surrounded the DCC server's security regarding versions prior to 5.51, so I recommend you take care in earlier versions. I never received official word of a problem, but there was enough smoke so fire seemed a distinct possibility. To view the full
list of DCC Server commands, click on the Help button while in the DCC or DCC Server menu—it's a bit hard to find the list from the help menu.
Sound-Related DCC
A lot of people play sounds on IRC.
Well, they don't play the sounds, they just tell other people's clients to play them—and that's the snag in the whole sound affair.
In order to play a sound, the recipient of the request needs to have the sound file on his machine. Of course, with hundreds and hundreds of different WAV and MID files floating around, the chances that two users have the same set of audio files are remote. Because there are so many, no single person has the disk space to store all the sounds encountered on IRC.
To address this problem, the procedure of asking the person who sent the sound request for the audio file is automatic. In addition to that, mIRC also allows you to send out a sound file automatically if asked, acting as a limited form of file server, as well as automatically request an audio file you don't have. The command for initiating this is:
!nickname
I recommend you keep the option of sending the request in the form of a private message instead of sending requests to a channel.
Both these options are under File • Options • Sound • Requests.
Before you throw something at me, I'll stop reminding you of the risks of accepting files from strangers.
More DCC Options and the Big Secret
Under DCC's Options menu, you'll find a set of check boxes defining what happens after a DCC transfer is completed. They don't need much explaining, but it's probably best if you close the windows after completion. Whether you want a beep each time a DCC session ends is entirely up to you. You will also see a section for timeouts. These regulate how much time your client allows to pass before voiding a DCC CHAT or SEND request and closing the corresponding port. If the recipient of the request doesn't accept your offer within the specified time, it simply gets cancelled. The DCC get timeout is not as important; it basically just clears the request from the list if you let it time out.
To allow for lag that would delay your DCC request on its way to the receiver, don't make the figures too low. A minimum of 120 seconds is reasonable. It also should not be too high, so as to avoid leaving too many pending offers with open ports.
The Big Secret? What secret? Ah, yes, the one I promised in the title. It's not so much a secret as a feature the client's help files don't document. PDCC (pump DCC) actually constitutes a slap in the face of everything sacred in TCP/IP networking. What it does is defy conventions and rules and simply pump data packets down the line as fast as it can, in the hope that they'll all arrive. TCP requires acknowledgement of receipt for the previous data packet before sending the next, but PDCC makes it shovel data down the line almost as fast as your connection can take it. If the packets don't all make it to the destination, you end up with a corrupt file. It's actually surprisingly reliable considering how technically unsound the idea is, so I don't rule it out as an option to speed up your DCC sends. The magic command is:
/pdcc some_arbitrary_large_number
The number is of little importance—most people simply enter a string of five or six nines. Good luck with it.
DCC from Behind a Firewall or Proxy
A firewall was originally a machine designed to protect other machines from unauthorized access, and this is the strict meaning of the term.
Nowadays, they also protect the systems behind them from other kinds of attack. There are also programs that run on the protected machine itself, inspect incoming traffic before letting it pass, and filter it to rejec potentially harmful data. These software firewalls are generally over- rated—their inherent weakness is that they allow data to reach the machine in the first place. They're about as good as a bulletproof vest compared to the concrete barrier of a firewall machine.
Most firewalls work on a basis of "forbid all, allow specific"—that is, they reject everything not expressly allowed to pass according to its configuration. Typical firewall setups permit any connection from inside the firewall to an outside host, but allow only certain outside hosts (or all) to connect to a strictly defined set of ports serving a particular purpose.
The problem with DCC is that it is a protocol that uses arbitrary or semirandom ports for its connections. So if your client tells the recipient of your DCC request to connect to port 5532 and expects a connection on that port, this means nothing to the firewall. It sees an attempt to connect to port 5532, thinks "What the heck is that?" and tosses it out. More than that, if the firewall is on a machine other than the client's, all connections you make appear to originate from that machine and not your own. This makes DCC very tricky. If you have such a setup, there's a good chance you will not be able to initiate DCC connections.
If you're not running the firewall yourself, you don't stand much of a chance of getting DCC to work. For a software firewall such as Conseal on Windows, you may be able to make it work by limiting the number of ports mIRC uses for DCC (use DCC • Options and change the range to a number much more limited than the default, such as 5000 to 5005) and letting traffic to those ports pass. With any other setup, read your firewall's documentation carefully and see whether you can make it work. If not, you have to live without the ability to initiate DCC SEND
and CHAT connections. If the firewall is a separate machine and you can run your client on the firewall machine itself, do so.
Well, some of the worst technical stuff is over. Our next step brings us to a command set you'll find useful in seeing what's happening on the server and network around you.
to be continued... ;-)
Resources
THE BOOK OF IRC By Alexander Charalabidis
ISBN 1-886411-29-8
No Starch Press (2000)
A list of all Internet Relay Chat commands (from IETF RFCs 1459 and 2812)
CTCP spec
