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.

Netsplit

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.

Network Architecture

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.

Compression

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.

Routing.

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.