Requirements 
 License 

 Installation 
 IRC usage 
 Server connects 
 DCC sends 
 Logging 

 Format 
 Reference 
 Example 

 Roadmap 
 Download 
 Config parser 
 Visions & ideas 

Server connects

IRC servers may not always be available: they may be overloaded, taken down for maintenance or the user may have miswritten the hostname. MetalServe was designed to cope with this reality in a reactive and flexible way. This page explains the mechanism employed when establishing connections to IRC networks and describes the relevant configuration directives.

First, let's discuss some facts and conclusions that have found their way into MetalServe's IRC server connection mechanism:

• by design, if multiple IRC servers are connected with each other directly or indirectly, nicknames are unique across the entire IRC network. This means that connecting to another IRC server of the same network won't work, unless a different nickname is used.

  MetalServe could theoretically employ multiple connections, using the configured backup Nicknames (see the nickname directive's documentation), providing quick fallback possibilities if the primary connection to some server dies. However, this would not only make MetalServe unnecessarily complicated, it would also waste the resources of IRC servers for a rare case, yielding in unfair behaviour against other users that can't connect any longer.

• there is no single global IRC network. Instead there are a lot of smaller and some quiet large IRC networks, both in number of servers and number of users. These IRC networks are not connected under each other. MetalServe therefore supports connecting to multiple IRC networks in parallel, in order to maximize the number of users that can take advantage of the files being offered.

  However, there is no way to determine whether two servers belong to the same IRC network without a connection to at least one of the two, and even then it would be complicated and unreliable. It is therefore left up to the user to tell MetalServe in its configuration file, which IRC network consists of which servers.

• the more IRC users, the more load on a given server. Network- or server-side load-distribution mechanisms such as round-robin DNS may spread the load, but in a way totally unrelated to the actual load. It is imaginable that, in the worst case, a single server still gets way more load than the other servers.

  It is therefore common for the IRC clients to not just try to connect to one server, but employ some sort of selection algorhytm. In the simplest case they just try one server after the other, until a connection can be established. More sophisticated algorhytms might eg. measure the ping times.

First of all, the priority directive in server subsections allows to assign priorities to the listed servers, with the result that the server with the highest priority is tried first. This should ideally be a server not too far away from your location. Unless an IP address was specified, MetalServe tries to resolve the specified server name in the DNS (Domain Name System) -- if this fails, the server is marked as disabled. Otherwise MetalServe waits up to server_connect_timeout seconds for the connection to be established.

If the timeout is reached, the number of performed attempts for this server is increased and the earliest date for another attempt is calculated using server_connect_delay. Then the server with the next highest priority value is tried. If the last configured server has been reached, the process restarts with the first server.

However, servers that have seen more attempts than was configured with the server_connect_attempts directive will be disabled as well, until eventually the entire network has to be disabled because no server could be connected. Only if all networks fail, MetalServe will exit since there will be nobody left to be served.

There is one other timeout in effect: once a connection has been established, it may stall (ie. suddenly there's no more incoming data for an unusually long time). This may eg. be caused by a congestion somewhere in the Internet or an overload condition on the IRC server. In that case, MetalServe will wait up to server_timeout seconds until the connection is closed and the same procedure as if the server was not reachable is executed (see above).