Other Directory Sites: SeekWonder | Directory Owners Forum
The following archive was created by hippie-mail 7.98617-22 on Sat Apr 10 1999 - 01:11:01
Daniel Pittman (danielp@osa.de)
Thu, 27 Aug 1998 13:51:54 +0200
Mok-Kong Shen wrote:
[Multicast protocols]
> Could someone give a short yet concrete summary of the techniques
> currently employed by IRC?
Sure. I cannot speak for the latest and greatest enhanced networks, but
I know the basic network technology fairly well. I do not believe that
this has changed in fundamental use, just in the overlayed extensions.
The IRC network can be seen as an acyclic graph of servers, with clients
hanging off each server as leaf nodes. For the purposes of the actual
network itself, client software can be ignored, pretty much.
The basic architecture of the network is a hand woven system with links
between servers constructed and maintained by hand. Any loop in the
system will bring the entire thing to it's knees, while a dropped
connection between servers will break the network into two parts.
Message propogation is through a flooding algorythm. Each server on
reciept of a new message will flood it to every server it contacts, with
the exception of the originating server. Thus a message will jump from
server to server in an expanding ring, crossing the entire graph.
Private messages are passed from a server only to the targeted client,
while the channel concept is simply a list of client connections that
recieve input directed to the channel as a name.
The DCC (Direct Client Connection) protocol uses the network propogation
to establish the location of both participants, then opens a direct
TCP/IP connection between them, I believe.
Every byte of data from a client goes to every server, with no
intelligence in the routing. The fact it works at all on the current
scale is an amazement to me, given that for a long while the efNet
traffic was over twice the AU<->US link bandwidth, per day...
Incidentally, there have been a number of non-IETF efforts to improve
the network, including a few basic redesign attempts. I don't follow
their status any longer and thus could not tell you where they stand.
I trust this is what you were after, and I would be happy if someone
were to correct any technical (or nomenclature) errors of mine - it's
been a while since I looked at IRC.
As a side note this is a damn inefficient architecture, full of race
conditions that can be exploited and so forth. It also suffers from the
same sort of congestion storms that the RIP routing protocol does,
causing many communication delays.
Were I to rebuild it myself I would look at replacing the client/server
architecture with a distributed management system. Make each client
responsible for it's own internal channel management, route dynamically
between the participants using some variant on OSPF or a similar
protocol.
To achieve the same shared channel architecture, establish a solid query
protocol to achieve a list of active channels/groups managed by the
software on a given machine, and allow the big sites/networks to offer a
common meeting place to establish a shared connection, without needing
the server to be involved beyond that point.
This is just a rough set of ideas - I never bothered to develop them any
further, and they don't deal with some of the trickier issues of
optimizing the routing algorythm. I will happily give more details to
anyone who cares to ask, though...
Daniel
The following archive was created by hippie-mail 7.98617-22 on Sat Apr 10 1999 - 01:11:01