IRC - Internet Relay Chat.

The server forms the backbone of IRC, providing a point to which clients may connect to to talk to each other, and a point for other servers to connect to, forming an IRC network. The only network configuration allowed for IRC servers is that of a spanning tree where each server acts as a central node for the rest of the net it sees.
For example:

A client is anything connecting to a server that is not another server. Each client is distinguished from other clients by a unique nickname having a maximum length of nine (9) characters. Usually users choose a constant nickname, as our experience has taught us, although generally each time connecting to a server one can use a new nick name. We connect to the server by the following way:

irc Nick /SERVER irc.tau.ac.il

This means that a client that chooses the nickname Nick connects to the IRC-server of Tel-Aviv University.

In addition to the nickname, all servers must have the following information about all clients:

• The real name of the host that the client is running on.
• The username of the client on that host.
• The server to which the client is connected.

A channel is a named group of one or more clients which will all receive messages addressed to that channel. The channel is created implicitly when the first client joins it, and the channel ceases to exist when the last client leaves it. While channel exists, any client can reference the channel using the name of the channel.

To create a new channel or become part of an existing channel, a user is required to JOIN the channel. If the channel doesn't exist prior to joining, the channel is created.As part of the protocol, a user may be a part of several channels at once, but a limit of ten channels is recommended.

The JOIN command is used by client to start listening a specific channel. Whether or not a client is allowed to join a channel is checked only by the server the client is connected to; all other servers automatically add the user to the channel when it is received from other servers.

Before JOINing a channel a user might be intrested to know WHO is already listening to this channel. Then he (or she) uses the WHO command for example like this:

/who #israel

The printed information will include the nickname, the real name of the host, the username, the server of each user connected to this channel

Once a user has joined a channel, they receive notice about all commands their server receives which affect the channel. The JOIN command needs to be broadcast to all servers so that each server knows where to find the users who are on the channel.

If a JOINis successful, the user is then sent the channel's topic and the list of users who are on the channel .

Implementation.

Clients and servers are both subject to the same level of authentication. For both, an IP number to hostname lookup (and reverse check on this) is performed for all connections made to the server. Both connections are then subject to a password check (if there is a password set for that connection). These checks are possible on all connections although the password check is only commonly used with servers. An additional check that is becoming of more and more common is that of the username responsible for making the connection. Finding the username of the other end of the connection typically involves connecting to an authentication server such as IDENT. Let us look at the way the servers communicate with each other and the clients.

1. Network protocol: TCP - why it is best used here.
2. Message delivery.
3. Connection 'Liveness'.
4. Establishing a server to client connection.
5. Establishing a server-server connection.
6. Server exchange of state information when connecting.
7. Terminating server-client connection.
8. Terminating server-server connection.

IRC has been implemented on top of TCP since TCP supplies a reliable network protocol which is well suited to this scale of conferencing. The use of multicast IP is an alternative, but it is not widely available or supported at the present time.

It is common to find network links saturated or hosts to which you are sending data unable to send data. Although Unix typically handles this through the TCP window and internal buffers, the server often has large amounts of data to send (especially when a new server-server link forms) and the small buffers provided in the kernel are not enough for the outgoing queue. To alleviate this problem, a "send queue" is used as a FIFO queue for data to be sent. A typical "send queue" may grow to 200 Kbytes on a large IRC network with a slow network connection when a new server connects.

When polling its connections, a server will first read and parse all incoming data, queuing any data to be sent out. When all available input is processed, the queued data is sent. This reduces the number of write() system calls and helps TCP make bigger packets.

To detect when a connection has died or become unresponsive, the server must ping each of its connections that it doesn't get a response from in a given amount of time.

If a connection doesn't respond in time, its connection is closed using the appropriate procedures. A connection is also dropped if its sendq grows beyond the maximum allowed, because it is better to close a slow connection than have a server process block.

Upon connecting to an IRC server, a client is sent the MOTD (if present) as well as the current user/server count (as per the LUSER command). The server is also required to give an unambiguous message to the client which states its name and version as well as any other introductory messages which may be deemed appropriate.

After dealing with this, the server must then send out the new user's nickname and other information as supplied by itself (USER command) and as the server could discover (from DNS/authentication servers). The server must send this information out with NICK first followed by USER.

The process of establishing of a server-to-server connection is fraught with danger since there are many possible areas where problems can occur - the least of which are race conditions.

After a server has received a connection following by a PASS/SERVER pair which were recognised as being valid, the server should then reply with its own PASS/SERVER information for that connection as well as all of the other state information it knows about as described below.

When the initiating server receives a PASS/SERVER pair, it too then checks that the server responding is authenticated properly before accepting the connection to be that server.

The order of state information being exchanged between servers is essential. The required order is as follows:

• all known other servers;
• all known user information;
• all known channel information.

Information regarding servers is sent via extra SERVER messages. By passing the state information about servers first, any collisions with servers that already exist occur before nickname collisions due to a second server introducing a particular nickname. Due to the IRC network only being able to exist as an acyclic graph, it may be possible that the network has already reconnected in another location, the place where the collision occurs indicating where the net needs to split.

When a client connection closes, a QUIT message is generated on behalf of the client by the server to which the client connected. No other message is to be generated or used.

If a server-server connection is closed, either via a remotely generated SQUIT or 'natural' causes, the rest of the connected IRC network must have its information updated with by the server which detected the closure. The server then sends a list of SQUITs (one for each server behind that connection) and a list of QUITs (again, one for each client behind that connection).

Types of communication.

Communication on a one-to-one basis is usually only performed by clients, since most server-server traffic is not a result of servers talking only to each other. To provide a secure means for clients to talk to each other, it is required that all servers be able to send a message in exactly one direction along the spanning tree in order to reach any client. The path of a message being delivered is the shortest path between any two points on the spanning tree.

Example 1: A message between clients 1 and 2 is only seen by server A, which sends it straight to client 2.

Example 2: A message between clients 1 and 4 is seen by servers A & B, and client 3. No other clients or servers are allowed see the message.

Example 3: A message between clients 2 and 3 is seen by servers A, B, C & D and client 4 only.

The main goal of IRC is to provide a forum which allows easy and efficient conferencing (one to many conversations). IRC offers several means to achieve this, each serving its own purpose.

The least efficient style of one-to-many conversation is through clients talking to a 'list' of users. This is how it's done:

The client gives a list of destinations to which the message is to be delivered and the server breaks it up and dispatches a separate copy of the message to each given destination. This isn't as efficient as using a group since the destination list is broken up and the dispatch sent without checking to make sure duplicates aren't sent down each path.

In IRC the channel has a role equivalent to that of the multicast group; their existence is dynamic (coming and going as people join and leave channels) and the actual conversation carried out on a channel is only sent to servers which are supporting users on a given channel. If there are multiple users on a server in the same channel, the message text is sent only once to that server and then sent to each client on the channel. This action is then repeated for each client-server combination until the original message has fanned out and reached each member of the channel.


Example 4:

Any channel with 1 client in it. Messages to the channel go to the server and then nowhere else.

Example 5:

2 clients in a channel. All messages traverse a path as if they were private messages between the two clients outside a channel.

Example 6:

Clients 1, 2 and 3 in a channel. All messages to the channel are sent to all clients and only those servers which must be traversed by the message if it were a private message to a single client. If client 1 sends a message, it goes back to client 2 and then via server B to client 3.

To provide IRC operators with some mechanism to send messages to a large body of related users, host and server mask messages are provided. These messages are sent to users whose host or server information match that of the mask. The messages are only sent to locations where users are, in a fashion similar to that of channels.

The one-to-all type of message is better described as a broadcast message, sent to all clients or servers or both. On a large network of users and servers, a single message can result in a lot of traffic being sent over the network in an effort to reach all of the desired destinations.For some messages, there is no option but to broadcast it to all servers so that the state information held by each server is reasonably consistent between servers.

Applications based on IRC.

Today IRC doesn't just replace the old talk application and serves to implement a teleconferencing system it also became the base for very interesting applications. In our Project we pay describe two of them:

1. DCC.
2. Iphone.

DCC

1. Why DCC.
2. How.
3. DCC Connection Types.
4. Implementation.
5. Implementation details.

One of the problem in the way IRC protocol is implemented is that it doesn't provide the secure communication.The DCCprotocol is the ultimate way in secure chat connections and file transfer .It also allows the user to overcome some limitations of the IRC server network.
DCC uses direct TCP connections between the clients taking part to carry data. There is no flood control, so packets can be sent at full speed, and there is no dependance on server links (or load imposed on them). In addition, since only the initial handshake for DCC connections is passed through the IRC network, it is impossible servers to spy on DCC messages.

The initial socket for a DCC connection is created by the side that initiates (Offers) the connection. This socket should be a TCP socket bound to INADDR_ANY, listening for connections. The Initiating client, on creating the socket, should send its details to the target client using the CTCP command DCC.
This command takes the form:

  DCC type argument address port 

  type        - The connection type

  argument    - The connection type dependant argument

  address     - the host address of the initiator as an integer.

  port        - the port or the socket on which the initiator expects  to receive the connection.

The following DCC connection types are known to IRCII:

   Type                    Purpose			Argument


   
   CHAT	      To carry a secure conversation	    the string "chat"

   SEND	      To send a file to the recipient	    the file name


   In addition, the following are included in the IRCII DCC command, although they do not 
   transmit a DCC request via IRC:



   TALK      Establishes a TALK connection 

The CHAT and SEND connection types should not be accepted automatically as this would create the potential for terrorism. Instead, they should notify the user that an offer has been made, and allow the user to accept it.
The recipient should have the opportunity to rename a file send with the DCC SEND command prior to retrieving it. The following are the steps which should occur in the clients:

Initiator:

On a connection:

Acceptor:

CHAT Data sent across a CHAT connection should be sent line-by-line without any prefixes or commands. A CHAT connection ends when one party issues the DCC CLOSE command to their clients, which causes the socket to be closed and the information on the connection to be discarded.

FILE Data is sent in packets, rather than dumped in a stream manner. This allows the DCC SEND connection to survive where an FTP connection might fail. The size of the packets is up to the client, and may be set by the user. Smaller packets result in a higher probability of survival over bad links.The recipient should acknowledge each packet by transmitting the total number of bytes received as an unsigned, 4 byte integer in network byte order. The sender should not continue to transmit until the recipient has acknowledged all data already transmitted. Additionally, the sender should not close the connection until the last byte has been acknowledged by the recipient.

That it is not possible for the recipient to tell if the entire file has been received - only the sender has that information, although IRCII does not report it. One could verify the transfer by checking file sizes.