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.
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−HOWTOServer 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.
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 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.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.
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.
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 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,
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
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).
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 help08: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.
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.
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.
Go to File > Options > IRC Servers and check the Invisible Mode box. Add a
MODE $N +i
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 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.
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 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.
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.
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.
Each server you try to connect to gets added to
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
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.
/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.
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. This should not be possible and is a violation of the protocol, so the first server to detect such a thing issues a KILL
*** 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.
*** 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.
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.
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]
This type of quit is also associated with some of the DoS attacks (nukes)
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.
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.
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.
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.
Operator-set K: lines are effective immediately and result in instant disconnection of all clients matching the K: line, without allowing them to reconnect.
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).
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
Channels
You may know them as rooms from other online chat systems, but the correct
describe the difference between the old idea of entering rooms where some
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.
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 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.
Global channels, accessible from all servers of the given network, are - 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.
Channels beginning with & on different servers can have the same name, without interfering with each other.
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.
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).
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.
/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!
...
The number following the channel name is the number of users currently on the - 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.
-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.
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.
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.
Sending an email to the server asking its admin - 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.
data a server returns.
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.
Windows users should be able to reproduce them without too much trouble. IrcII-based clients can pro
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.
/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
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.
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:
... ... ... http://users.dal.net
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
*** 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.
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.
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.
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
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.
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.
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.
*** 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.
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.
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.
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.
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!
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) - 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.
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.
The first is being the first user to join a channel, in which case the - 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.
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.
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.
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).
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.
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, 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.
Bots are special programs that act as unsupervised clients on IRC.
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.
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.
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.
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.
The service robot isn't necessarily visible on the channel.
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
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.
*** Signoff: Hello4lm (Quit: Leaving)
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 [..]
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.
/part #somewhere
If your client lets you substitute an asterisk for the current channel,
/leave *
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.
/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
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.
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.
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.
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.
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).
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.
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.
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.
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).
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.
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.
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.
COMMUNICATION
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.
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.
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.
It does have the advantage of not returning the away message when you NOTICE a user who has set himself /away.
-Noticer- Thank you for joining us.
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.
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.
Wallops
Whether these are common or rare depends on your network. There are two forms,
one from IRC operators and the other from servers.
have user mode w set, and you don't really need it. You will not receive any unless you
!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.
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.
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
/msg @user
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)
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.
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.
Disagreements and the odd fight are a part of life, but insults aren't necessary.
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.
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 CRAP NONE Removes someone from the ignore list
/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 -n -P -t -uN - -r Removes the IGNORE from the nickname or host mask.
0 1 2 3 4 5 6 7 8 9
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.
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.
/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.
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.
/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.
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.
/query target
/query
corresponding.
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.
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.
Regarding color, clients almost universally follow mIRC. This color is not real ANSI color—it is exclusive to the IRC clients that support it.
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 ^V ^_
/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).
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 ^R ^U
^K 5 ^K 15,1 ^K 0,0
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.
/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.
//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.
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
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.
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.
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.
ON sendjnsg "*" echo <$N> $1-
FINDING PEOPLE ON IRC
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.
/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 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.
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).
/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.
Flag Type of Result
-name User name -nick Nickname -oper IRC operators only -chops Channel operators only -host Host name -server Server name only
/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.
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.
/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 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
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.
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)
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 - 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
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.
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.
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.
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]
the CTCP displayed, you have to script it yourself.
/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.
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.
received.
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 - your message telling them the result.
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.
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.
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.
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.
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.
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
(They automatically greet each other. This is only the beginning. What
if they're not programmed to stop responding automatically to each
others' greetings?)
. . . 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.
What we have now is the following:
You: PRIVMSG Doe : 0COMMAND parameters0
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
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.
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.
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.
/dec chat nickname
/dec close chat nickname
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.
/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.
DCC RESUME on mIRC and other clients following its lead breaks the protocol and entails the risk of entering an infinite loop.
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.
It's a good idea to check the script for back doors, too, if you decide to use one of them.
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.
!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.
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
Before you throw something at me, I'll stop reminding you of the risks of accepting files from strangers.
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.
Resources
THE BOOK OF IRC By Alexander CharalabidisISBN 1-886411-29-8
No Starch Press (2000)
A list of all Internet Relay Chat commands (from IETF RFCs 1459 and 2812)
CTCP spec
No comments:
Post a Comment