This chapter is from the book
This chapter is from the book
This chapter is from the book
IRC Network Basics
Having chosen a communication standard for the chat, we should take a look at how exactly IRC networks are built.
Ideally, you should have evaluated the IRC network basics discussed in this section prior to choosing IRC—since it's a bad thing to find out that IRC introduces a complicated structure after already having made the decision to use it. To this point, however, we've been working with "common knowledge" about using IRC networks, just for the sake of application planning. Now that we've led you to the "right" method to use for the application (IRC), this section provides the details you need to execute that plan.
IRC networks distinguish between clients and servers. Users can participate on the network only by using a special client software that establishes a client link to a server. All servers on the network are interconnected using special server links. Current implementations of IRC servers only support hierarchical structures, meaning that there must not be redundant ways to reach a server. This forms the net into a tree-like structure prone to network splits, but also greatly simplifies routing: All servers simply have to send all incoming data to all other links, without fearing to send redundant information to a server.
Each server can have a number of clients; the maximum number depends on the number of connections the server is willing to accept (of course, limits also exist in terms of network capacity and server load). As shown in Figure 3.2, each server can reach every other server across more or fewer server hops, so each server simply sends all incoming data to all outgoing links. For example, Server C and Server F might carry clients participating in the same channel (channels are IRC's chat rooms—places where people can "meet" and "talk"). In this example, Server C would send the data via the only link it has: Server B. Server B then distributes the data to its other links, namely Server A and Server D. Server A doesn't have any other links, so it won't do anything, but Server D would pass on the data to Server E, and Server E in turn to Server F. Pretty easy to implement, but with one drawback: If Server A doesn't have any clients connected to it participating in the channels to which Server C sends data, all data for Server A targeted at this channel would simply waste bandwidth.
RFC for IRC
Similar to all open standards on the Internet, the basics of the IRC protocol have been specified in an RFC (Request For Comments). The RFC for IRC is RFC 1459, which can be retrieved, for example, at http://www.irchelp.org, a site that carries a lot of information on IRC.
)
Figure 3.2. A sample IRC network structure.
This is one of the main problems of this "limited by design" network: All public traffic has to go to all servers. But will this problem really arise under the conditions in which we intend to implement our IRC network? Surely not, as the number of clients we intend to handle will never be so large as to be harmful, given a standard server-hosting situation. In internal networks, this problem shouldn't arise at all.
To reduce the total number of critical links, the network can be laid out to follow its physical topology. If one server is connected with higher capacity than the rest, for example, it can take more leaf nodes than others (connecting lots of leaf nodes to a server with a small backbone wouldn't even make sense). Another option is to set up the routing to fit the network. For example, U.S. servers are homed in the States, German servers are homed in Germany, and so on. Frankfurt has an overseas link to New York; thus, the IRC server in Frankfurt should link to New York's server (following the network's physical layout). It could also be done in another way: Frankfurt could link to, say, Poland. But if Poland doesn't have its own overseas link, the traffic routed from Frankfurt to Poland would need to find some other way to cross the ocean—it would be routed to some other country (or even two or three countries) until it finds a free overseas link. This additional routing wastes a lot of bandwidth; thus, attempts are being made to adapt the IRC network structure to best fit the underlying physical network structure.
These design problems are present only in the biggest networks, carrying tens of thousands of users. These networks really need to find reliable links for their backbones. Typical Web-based chat rooms or networks are unlikely to carry more than 1,000 clients at once, so you shouldn't run into serious problems at first. To avoid complications, however, it's a good idea to plan around these sorts of problems that may arise eventually.
From a server's point of view, the network looks like Figure 3.3.
)
Figure 3.3. Network structure from a server's point of view.
The structure implemented here is similar to a mixture of a multiplexor, demultiplexor, and a hub. In the direction client to network, the server compresses all data from the clients and sends it to the network links. In the other direction, it determines which information from the network is important for which client and sends it to the appropriate link. All incoming data from the network that has to be passed on to the other network links is sent on directly.
Basically, this is the setup we'd need for our own chat system. Now take a minute and try to imagine how we can achieve our goal. We need a working server environment that fits the following description:
-
Accepts IRC network links
-
Accepts IRC client links
-
Provides a Web-based user interface
-
Is as easy to implement as possible