Internet relay chat

from Wikipedia, the free encyclopedia
IRC (Internet Relay Chat)
Family: Internet protocol family
Operation area: Messaging, social networks
Port: 194 / TCP Official,
6667 / TCP Often used
6696 / TCP Often used for TLS connections
IRC in the TCP / IP protocol stack :
application IRC
transport TCP
Internet IP ( IPv4 , IPv6 )
Network access Ethernet Token
bus
Token
ring
FDDI ...
Standards: RFC 1459 (1993)

RFC 2810-2813 (2000)

Scheme of an IRC network with clients (angular), including normal users (green), bouncers (orange), bots (bluish) and IRC services

Internet Relay Chat , or IRC for short , is a text-based chat system. It enables discussion groups with any number of participants in so-called conversation channels ("channels"), but also discussions with only two partners (query). New channels can be opened by any participant, and you can also take part in several channel conversations at the same time.

A network program is required for dial-in , whereby this "IRC client" can be an independent program on the local computer (e.g. mIRC , XChat ) or just a user interface in the Internet browser .

An IRC network consisting of interconnected servers (the " relay " stations) is used to mediate the calls in the IRC . The essential feature of this network is its communication topology adopted by BITNET , according to which there is always only one communication path between any two participants. Historically, this ensured efficient communication, because in the early days of the IRC, intercontinental data lines had a very limited capacity. The topology made it possible that a message from a client on one continent did not have to be sent individually over the intercontinental line for each client on the other continent, but only once to a local server, which then distributed it to the clients. In spite of limited management capacities, very large “chat landscapes” were possible. The disadvantage of the principle is the lack of redundancy, which manifests itself in net splits: If any server fails , the network automatically breaks down into separate parts until a new connection is established in between.

The largest IRC networks consist of several dozen IRC servers that simultaneously connect over 100,000 users and manage tens of thousands of channels, in which several thousand people can participate at the same time. Despite these enormous proportions, the delay in a sent text is usually on the order of tenths of a second and only rarely exceeds the second mark.

development

The first IRC server, tolsun.oulu.fi ( Sun-3 )

The original idea of ​​a chat network emerged in BITNET under the name Relay Chat . This system was transferred to the Internet in the summer of 1988 by the Finnish student Jarkko Oikarinen , who studied at the Faculty of Computer Science at the University of Oulu .

Over time, the network grew to such a size that on the one hand technical problems arose and on the other it became too confusing and chaotic. Therefore, from around 1993, further independent, smaller networks emerged. In summer 1996 the original network was split due to differences between the operators. These parts can be found today in the IRCnet (mostly European operators) and in the EFnet (mainly operators in the USA ). Today there are thousands of independent networks. Large networks with more than 50,000 clients connected at the same time are QuakeNet , EFnet, IRCnet, Undernet and Freenode , while smaller networks include DALnet , euIRCnet , FurNet or GameSurge . All networks can also due to network problems or -überlastung netsplits occur.

The networks differ in terms of their regional focus, languages, topics and services offered. Acceptance or tolerance of sex and channels for distributing black copies also play an increasingly important role. The chat system is text-based, but also allows the exchange of files and other information via a direct client-to-client connection (DCC) between two users via additional commands . Automated DCC download options are also called XDCC .

protocol

In the original IRC one to get IP and TCP -based, text-oriented protocol used.

User-induced commands

It is common with IRC that users intervene directly in the communication between their client and the IRC server by sending their own messages / commands.

An example of a frequently used command is / whois nickname , which can usually just as easily be entered in a text field on the IRC client. The preceding slash ( / ) signals to the IRC client that this is a message that it should transmit to the IRC server in this form. The client sends the server whois nickname , where whois represents the command and nickname the parameter.

communication

All communication between client and server and the servers with each other is handled via messages in command form with a maximum length of 512 characters including line breaks that terminate the command.

A message consists of a sender ( prefix ), a (command- command ) and additional command parameters. The parameters and whether any are necessary at all depend on the respective command. In the case of commands from the client to the server, the sender is usually left out, since no other sender than the client itself is possible.

Servers only exchange messages with one another with details of the sender, since servers often only route messages through , and the destination and source of a message are required information.

In response to a message from a client, a server, a response message ( reply email) that a reply code has. This is a three-digit number with a clearly defined meaning. Here too, however, due to lack of agreement, the meaning differs from network to network.

By default, the IRC protocol causes a lot of control effort (overhead) between the servers due to the relatively long names of the commands, which in turn results in an unnecessarily high amount of data traffic. In order to reduce costs, a special server-to-server protocol is used in some IRC networks which, for example, provides a so-called token instead of the complete command for communication between the servers (for example "P" instead of "PRIVMSG") ).

Extensions

There are many independent protocol extensions for IRC. Many commands were added or their syntax expanded. Often the so-called channel modes and user modes have been expanded to include new modes. However, the development of these expansions was largely independent of one another and was unorganized in the various IRC networks and generally depends on the IRC server software used .

There is therefore insufficient documentation and standardization of these extensions. RFC 1459 describes the original protocol, most of which mechanisms and commands are still valid today and are the basis for other extensions of the protocol. Nevertheless, various details described are no longer up-to-date due to the further development of the server software in the individual IRC networks and are also nowhere centrally documented in their new form.

There are also RFC 2810 , RFC 2811 , RFC 2812 and RFC 2813 . In practice, however, they are of little or no importance, as they were written single-handedly by Christophe Kalt, the programmer of IRCnet version 2.9. Especially in the area of ​​communication between servers within a network, shortened (and therefore incompatible) modifications of the protocol are sometimes used.

Encryption

IRC can be used in its basic form unencrypted , but can also be used on most networks via an SSL / TLS -encrypted connection. It is also possible to encrypt messages across clients on the client side.

One possibility is encryption with FiSH . FiSH encrypts channels using a symmetrical cryptosystem . For this purpose, a key is specified for the channel to be encrypted, which must be communicated to all participants. The channel can be entered without the key (provided it does not require a password or the channel mode + i (invite only) is set), but the communication via this is illegible. FiSH also offers the option of securing private conversations (queries) between two participants. An asymmetrical cryptosystem is used here. A key is negotiated between the participants by means of Diffie-Hellman key exchange . FiSH plug-ins are available for common IRC clients such as mIRC , XChat or irssi . On Android , AndroIRC offers FiSH support.

Off-the-Record Messaging (OTR) is another encryption option . In contrast to FiSH, OTR relies exclusively on a public key method , an asymmetrical cryptosystem . The Diffie-Hellman key exchange is also used here . OTR can therefore only encrypt the query, but not the entire communication in a channel. OTR is available as a plug-in for Pidgin , XChat and irssi .

Character sets

Since no character set is specified (as is the case with XMPP, for example ) and there is also no possibility of specifying the one used at the protocol level, there can always be incorrect or unrepresented characters due to different character sets. Some clients try to guess the character set used by the senders, but this cannot function reliably because of the principle that certain byte sequences are valid in different character sets, but lead to different interpretations.

Started

In order to be able to participate in IRC, a so-called IRC client is required as a chat program, which establishes the connection to an IRC server . Since IRC is one of the more established and older standards on the Internet, there is a large selection of IRC clients these days.

Most of the IRC clients already have a selection of well-known IRC networks and their servers stored that you can connect to. After the connection with a server has been established, it is possible to have the available channels listed with the LIST command. Many networks also support a search with wildcards .

Channels

Communication with a group of users is carried out within a so-called channels ( English for channel ). Channels are marked with a preceding # . With the command /listthe channels of the IRC server to which you are connected can be displayed. The command /join #channelnamecan be used to join a channel.

If a channel that does not yet exist is entered, the IRC server usually creates it and gives the user control rights over the channel ( channel operator , or ChanOP for short ). As soon as the last user leaves a channel, the channel is terminated. Many IRC networks, however, offer bots or services for channels , which in this case "manage" the channel and give back their rights to the relevant users as soon as they re-enter the channel, as well as allowing a finer management of the channel.

For this purpose, nicknames and channel names are registered. In support channels, often named similarly to #irchelp, #help, #hilfe or #helpdesk, users can inquire about the individual commands.

Some networks do not offer such services because they do not grant any ownership rights for a channel or a nickname . Here the “founder” of the channel is responsible for maintaining his rights.

This fact sometimes leads to virtual wars, which are carried out with legal as well as illegal means in order to gain control over a channel (takeover).

behaviour rules

On the website of the respective network or in the MOTD , which is displayed at Connect, you can usually find information about the rules of conduct to be observed and other network-specific features.

safety

As is generally the case on the Internet , users should also pay attention to security in IRC, since accepting file transfers from unknown users or carelessness can lead to passwords being spied on or a virus attack on one's own computer. You should also note that with an unencrypted connection (without SSL / TLS ), eavesdropping on conversations and passwords may be possible.

See also

Web links

Individual evidence

  1. a b c RFC 1459 Section 1