 |
 |
 |
|
|
|
| What
are IRC ? |
Presented by: |  Copyright 2000© |
|
|
IRC, Internet Relay Chat, is a real-time conversational system. It is similar to the talk command which is available on many machines in the Internet. The IRC protocol has been designed over a number of years for use with text based conferencing. It has been developed on systems using the TCP/IP network protocol, although there is no requirement that this remain the only sphere in which it operates. Through the use of the client-server model IRC is well-suited to running on many machines in a distributed fashion.
IRC is an example of the communication systems in which both one-to-one and one-to-many or as we studied in the class monocasting and broadcasting models are implemented. A typical setup involves a single process (the server) forming a central point for clients (or other servers) to connect to, performing the required message delivery/multiplexing and other function .
IRC is networked over much of North America, Europe, and Asia. When you are talking in IRC, everything you type can instantly be transmitted around the world to other users who are connected at the time. They can then type something and respond to your messages. Topics of discussion on IRC are varied. Technical and political discussions are popular, especially when world events are in progress. IRC is also a way to expand your horizons, as people from many countries and cultures are on, 24 hours a day. Most conversations are in English, but there are always channels in German, Japanese, Finnish, Russian and occasionally other languages.
Some of channels are almost permanent and reappear instantly after rebooting of the system. A good example for such channels is : #russian or #israel. Now and then we 'meet' there our friends that we know only by the IRC nick names and never saw them. In both channels the main part of users are Israeli students. Talking goes on in Hebrew, Russian and sometimes in English.
Here is a Table of Contents for our project:
Definitions
of terms
Implementation
Types
of Communication
Applications based on IRC
Recent developments and
problems
Summary
Credits
About the authors.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:
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:
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:
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 .
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.
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:
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).
 |
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.
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:
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.
We can say that IRC is a system of
the future. Together with the implementations of Video and Audio
communication applications (Good example of such an application is Iphone)
,the speed improvements and protocols enhancements, it will allow to
overcome the distances between people and continents and to bring
the communications to the totally new level .To the level of the 21
century .
Another interesting application based on IRC is Iphone.Iphone is a
shortcut for Internet Phone and it provides the users accross the
world with the means to analog voice communication. The motto is
"Talk for free over the Internet". Developed by an Israeli
company Vocaltec. Iphone uses IRC to discover the Internet
address of the caller and the the one of the receiver to set up the
channel and then uses UDP to transfer voice.Being a connectionles
type of protocol UDP is well suited to transfer voice because it
speeds up the the data transfer and relatively high error rate is
insignificant here because we transfer voice.
Summary.
Recent
developments and problems.
Introduction
Netsplits
Network
Architechture
Compression
Routing
Introduction
After the concept of IRC has been introduced and various servers were established they formed a net called EFnet.Through the first 3 years of it existence the maximum number of of people connected to the IRC network (EFnet was the only one then) didn't exceed 700.At that time the structure of IRC network (Spanning Tree as one might recall) didn't cause any problem to appropriate functioning of the net furthermore the tree structure of the IRC network has made message routing an easy task in turn making connection between the servers quick and reliable.
But with the time the popularity of
the IRC had grown and so had the number of the users connected to
the IRC net then the tree structure became unreliable and the
Netsplits started becoming a part of IRC net inhabitants everyday
life.
Because of the tree structure ,once one server is down, the net splits in two Once the server comes up again, the flow of data can be so great that it either crashes again, or other servers might crash. And when it does work, the servers on top of the tree need to be mighty powerful to stuff all the information through.
As the population grew beyond 2500, netsplits got so frequent that people started up alternative IRC networks. The one we might mention is Undernet. But EFnet remained the largest public accessible IRC network and its population grew up to 10000 inhabitants.
Those netsplits made IRC net unstable and the concept has started to loose it charm. Recently number of developers had reached the conclusion that new IRC protocol needed to be proposed.
Here we cover the protocol between the servers alone.Because this part the IRC protocol could make the IRC network(s) more robust and efficient.
In the modern world of communication the the protocol should prevent netsplits even if the servers are down.To be able to do this we might implement a WEB-like architecture which would allow routing the message around the servers that are currently down. Instead of one server connecting to another and receiving connections from many others, it should be able to connect to several servers as well. This architecture will also add to security of the IRC net which is one of its weak sides.
To reduce amount of data send through the network we could use a known compression techniques, like Huffman compression.(We could do that because 90% of the traffic is text) However, instead of making some nice tables and transfer these for each line of text, we could simply set up a log on different channels on IRC today, analyze the contents and create a nice Huffman tree from it. The set tree would be global, and hopefully, efficient.However this method increases the CPU time needed to support the IRC network.
In the new routing scheme, servers don't know the entire route. If a server has a connection c_1 to c_n to server s_1 to s_n, then it stores for each possible destination server d a sorted list of connections. The connection in front of the list is the first step of the fastest route to the destination server. The next connection is the second-fastest etcetera.
This information is obtained by listening to (spurious) broadcasts from servers: if server d broadcasts a message, for example when a user on it has created a new channel, it sends this message across all its connections. The broadcast is stamped with its id (d, a 32bit number) and a sequence number. The servers around it remember that they have seen this broadcast, and pass it on if it is the first time they see it. Furthermore, if it is the first time they see it, they clear their routing list for server d, and put the connection at which the broadcast message arrived in front. Any following copy of the broadcast causes the link to be added at the tail of the list.
So after a while, a sorted list of connections is created.
If a server wants to send something to a set s of servers, it finds for each server in the set the fastest connection, constructs a message consisting of the subset of servers to be reached via a particular connection, and passes the message across that connection to the next server. This server does the same, until each server that was in the set s receives a copy of the message.
No explicit routing information is needed; all routing information is deduced from the broadcasts that are needed anyway for the few things that _every_ server needs to know.
This protocol reduces amount of bandwidth needed, the amount of server memory needed, and wipes out the concept "netsplit". Furthermore, algorithms are possible to setup a spanning tree for each server that carries a #report channel. This is (!) entirely NOT like the spanning tree IRC uses: IRC's spanning tree doesn't have a specific root, causing routes to become sub(subsub)optimal.
The longest path any message will
travel to set up the spanning tree, is 2d if d is the maximum of the
distances between the servers (called the "diameter" of
the graph).
Click here to the list of other IRC related RFC's
Also thanks to folks from alt.irc who helped me with my various questions and provided me with material for the DCC part.
Special thanks to Gard E Abrahamsen Whose ideas I used for the "Recent developments .. " part except for the routing algorithm which is due to G. Hiddink ( Homepage )
|
Home
| Search
| About |
Offices
| Manufacturers |
Products
| Services |
Ordering |
| Copyright© 2008 [Pulse, Inc.]. All rights reserved. Tel: (toll free): 888-785-7393 Int'l: 1-951-694-1173 Fax: 1-951-694-1173 Sales: sales |
