| Internet Relay Chat |
Article Index for Internet |
Website Links For Internet Relay Chat |
Information AboutInternet Relay Chat |
| CATEGORIES ABOUT INTERNET RELAY CHAT | |
| irc | |
| virtual communities | |
| on-line chat | |
|
Internet Relay Chat (IRC) is a form of real-time Internet Chat or Synchronous Conferencing . It is mainly designed for group ( Many-to-many ) communication in discussion forums called '' Channels '', but also allows One-to-one Communication and data transfers via Private Message . IRC was created by Jarkko "WiZ" Oikarinen in late August 1988 to replace a program called MUT (MultiUser Talk ) on a BBS called OuluBox in Finland . Oikarinen found inspiration in a chat system known as Bitnet Relay , which operated on the BITNET . IRC gained prominence when it was used to report on the Soviet Coup Attempt Of 1991 throughout a Media Blackout . It was previously used in a similar fashion by Kuwaiti s during the Iraqi Invasion . Relevant logs are available from ibiblio archive. IRC Client Software is available for virtually every computer operating system. TECHNICAL INFORMATION , an IRC client.]] , a Console based IRC client, in use on Mac OS X . Shown are two IRC channels and a private conversation with the software author.]] IRC is an open Protocol that uses TCP and optionally SSL . An IRC server can connect to other IRC servers to expand the IRC network. Users access IRC networks by connecting a client to a server. There are many client and server implementations, such as MIRC and the Bahamut IRCd. Most IRC servers do not require users to log in, but a user will have to set a nickname before being connected. IRC was originally a by IANA ; although, the de facto has always been running on 6667/TCP and nearby port numbers to avoid having to run the IRCd software with Root Privileges . It is possible (though quite inconvenient) to use IRC via a basic byte-stream client such as Netcat or Telnet . The protocol specified that characters were 8 bit but did not specify the character encoding the text was supposed to use. RFC 1459 This can cause problems when users using different clients and/or different platforms want to converse. All client-to-server IRC protocols in use today are descended from the protocol implemented in the irc2.8 version of the IRC2server, and documented in RFC 1459. Since RFC 1459 was published, the new features in the irc2.10 implementation led to the publication of several revised protocol documents; RFC 2810, RFC 2811, RFC 2812 and RFC 2813, however these protocol changes have not been widely adopted among other implementations. Although many specifications on the IRC protocol have been published, there is no official specification, as the protocol remains dynamic. Virtually no clients and very few servers rely strictly on the above RFCs as a reference. Microsoft made an extension for IRC in 1998 via the proprietary IRCX . They later stopped distributing software supporting IRCX, instead developing the proprietary MSN .NET Messenger Service The standard structure of a network of IRC servers is a tree ( Acyclic Graph ). Messages are routed along only necessary branches of the tree but network state is sent to every server and there is generally a high degree of implicit trust between servers. This architecture has a number of problems; a misbehaving or malicious server can cause major damage to the network, any changes in structure whether intentional or a result of conditions on the underlying network require a net-split and net-join resulting in a lot of network traffic and spurious quit/join messages to users and temporary loss of communication and adding a server to a large network means a large background bandwidth load on the network and a large memory load on the server. For a discussion of the evolution of server-side IRC protocols and the various IRCd incarnations, please see the separate article on IRC Daemon s. Commands and replies See Also: List of Internet Relay Chat commands IRC is based on a line-based structure with the client sending single-line messages to the server, receiving replies to those messages and receiving copies of some messages sent by other clients. In most clients users can enter commands by prefixing them with /; depending on the command, these may either be passed directly to the server (generally used for commands the client does not recognise), passed to the server with some modification or handled entirely by the client. Due to the nature of the protocol, it is impossible for automated systems to pair a sent command with its reply. Channels The basic means of communication in an established IRC session is a ''channel''. You can see all the channels in a server using the command ''/list [-min # # '' that lists all currently available channels, optionally Filter ing for parameters (#string for the entire or part of the name, with Wildcard s, and #min / #max for number of users in the channel). Users can ''join'' to a channel using the command ''/join #channelname'' and send messages to it, which are relayed to all other users on the same channel. Channels that are available across an entire IRC network are prepended with a ' # ', while those local to a server use '&'. Other non-standard and less common channel types include '+' channels — 'modeless' channels without operators, and '!' channels, a form of channel on normally non-timestamped networks. Modes Users and channels may have ''modes'', which are represented by single case-sensitive letters and are set using the mode command. User modes and channel modes are separate and can use the same letter to mean different things (e.g. usermode "i" is invisible mode whilst channelmode "i" is invite only). Modes are usually set and unset using the mode command which takes a target (user or channel), a set of modes to set (+) or unset (-) and any parameters the modes need. Some but not all channel modes take parameters and some channel modes apply to a user on a channel or add or remove a mask (e.g. a ban mask) from a list associated with the channel rather than applying to the channel as a whole. Modes that apply to users on a channel have an associated symbol which is used to represent the mode in names replies (sent to clients on first joining a channel and use of the names command) and in most clients to represent it in this list of users in the channel. In order to correctly parse incoming mode messages and track channel state the client must know which mode is of which type and for the modes that apply to a user on a channel which symbol goes with which letter. In early implementations of IRC this had to be hard-coded in the client but there is now a de-facto standard extension to the protocol which sends this information to the client at connect time. There is a small design fault in IRC regarding modes that apply to users on channels, the names message used to establish initial channel state can only send one such mode per user on the channel, but multiple such modes can be set on a single user. For example, if a user holds both operator status (+o) and voice status (+v) on a channel, a new client will be unable to know the less precedented mode (voice). Workarounds for this are possible on both the client and server side but none are widely implemented. Many ircd coders have added extra modes or modified the behavior of modes in the above list so it is strongly advisable to check the documentation of the irc network or ircd (though note that the network may have patched the ircd) for more detailed information on what the modes do on a particular server or network. IRC operators There are also users whose privileges extend to whole servers or networks of servers; these are called IRC Operators . On some IRC implementations, IRC operators are also given channel operator status in every channel, although many people believe that administration of channels and administration of the network should be kept separate, and that IRC operator status does not confer the right to interfere with a particular channel's operation. Attacks Because IRC connections are usually unencrypted and typically span long time periods, they are an attractive target for malicious hackers. Because of this, careful security policy is necessary to ensure that an IRC network is not susceptible to an attack such as an IRC Takeover war. IRC networks may also K-line or G-line users or networks that have a harming effect. A small number of IRC servers support SSL connections for security purposes. This helps stop the use of Packet Sniffer programs to obtain the passwords of IRC users, but has little use beyond this scope due to the public nature of IRC channels. SSL connections require both client and server support (which may require the user to install SSL binaries and IRC client specific patches or modules on their computers). IRC served as an early laboratory for many kinds of Internet attacks, such as using fake ICMP unreachable messages to break TCP -based IRC connections (" Nuking ") to annoy users or facilitate Takeover s. Abuse prevention: Timestamping vs. nick/channel delay protocol One of the most contentious technical issues surrounding IRC implementations, which survives to this day, is the merit of "Nick/Channel Delay" vs. "TimeStamp" protocols. Both methods exist to solve the problem of Denial-of-service Attack s, but take very different approaches. The problem with the original IRC protocol as implemented was that when two servers split and rejoined, the two sides of the network would simply merge their channels. If a user could join on a "split" server, where a channel which existed on the other side of the network was empty, and gain operator status, they would become a channel operator of the "combined" channel after the Netsplit ended; if a user took a nickname which existed on the other side of the network, the server would kill both users when rejoining. This was often abused to "mass-kill" all users on a channel, thus creating "opless" channels where no operators were present to deal with abuse. Apart from causing problems within IRC, this encouraged people to conduct denial of service attacks against IRC servers in order to cause Netsplit s, which they would then abuse. Nick/channel delay The nick/channel delay (abbreviated ND/CD) solution to this problem was very simple. After a user signed off and the Nickname became available, or a channel ceased to exist because all its users left (as often happens during a Netsplit ), the server would not allow any user to use that nickname or join that channel, respectively, until a certain period of time (the ''delay'') had passed. The idea behind this was that even if a Netsplit occurred, it was useless to an abuser because they could not take the nickname or gain operator status on a channel, and thus no collision of a nickname or 'merging' of a channel could occur. To some extent, this inconvenienced legitimate users, who might be forced to briefly use a different name (appending an underscore was popular) after rejoining. Timestamping The alternative, the timestamp or ''TS'' protocol, took a different approach. Every nickname and channel on the network was assigned a timestamp -- the date and time when it was created. When a Netsplit occurred, two users on each side were free to use the same nickname or channel, but when the two sides were joined, only one could survive. In the case of nicknames, the newer user, according to their TS, was killed; when a channel collided, the members (users on the channel) were merged, but the channel operators on the "losing" side of the split were de-opped. TS is a much more complicated protocol than ND/CD, both in design and implementation, and despite having gone through several revisions, some implementations still have problems with "desyncs" (where two servers on the same network disagree about the current state of the network), and allowing too much leniency in what was allowed by the 'losing' side. Under the original TS protocols, for example, there was no protection against users setting bans or other modes in the losing channel which would then be merged when the split rejoined, even though the users who had set those modes were no longer opped. Some modern TS-based IRC servers have also incorporated some form of ND and/or CD in addition to timestamping in an attempt to further curb abuse. There is not, and likely never will be, a consensus on timestamping vs. delay; however most networks today use the timestamping approach. It was part of the issues and disagreements which caused several servers to split away from EFnet and form the newer IRCnet (EFnet after the split moving to a TS protocol, and IRCnet using ND/CD), and supporters on both sides were known for heated arguments regarding the merits of their solution. NETWORKS AND URLS There are thousands of running IRC networks in the world. They run various implementations of IRC Servers , and are administered by various groups of IRC Operator s, but the protocol exposed to IRC users is very similar, and all IRC networks can be accessed by the same client software. One can join servers by clicking on a The largest IRC networks have traditionally been grouped in ''The Big Four'' — a designation for networks that top the statistics. The Big Four networks change periodically, but due to the community nature of IRC there are a large number of other networks for users to choose from. The Big Four: For network statistics, rankings, and a list of smaller networks, see netsplit.de , Search IRC and Gogloom . For other articles on IRC networks, see . CLIENTS To connect to an IRC network, people most commonly will connect to a IRC network via a IRC client. The client takes the raw IRC traffic and turns it into a easy-to-use interface, removing the need for the user to know the IRC commands specified in RFC 1459 , and later in RFC 2812 . The client also simplifies some commands, like turning PRIVMSG into MSG, and also allowing the user to talk more freely. For example, instead of a user having to type the entire line "PRIVMSG #Wikipedia :Hey guys!" the user would only need to type into the channel window "Hey Guys!". Another example is a user identify to a IRC service. Instead of typing "PRIVMSG NickServ IDENTIFY ilikewikipedia", the user types "/AUTH ilikewikipedia". IRC clients also will convert some of the raw data into windows, like turning channel traffic and the user list sent when a user first enters a channel into two windows. There are a great deal of IRC clients available, and are mostly separated by Operating System .
|
|
|