can any one explane how to set up a irc server pool better know as around robbin server trying to set up one for domain dbrotherhood.info

believe it or not, its really easy.

personally i run 6 ircd's, and have simply created the irc.domain.com a record for each ip, so that basically i have 6 anames for irc.domain.com but they all point to diff servers, and usually the server that you are directed to is the closest to your ip

hope that helps

OutHOST is correct. Round robin is pretty easy to achieve through DNS with multiple A records.

Major IRC networks used this system in the past with pretty good success. I can't speak for whether it's still used, but it worked pretty well back then.

-mike

believe it or not, its really easy.

personally i run 6 ircd's, and have simply created the irc.domain.com a record for each ip, so that basically i have 6 anames for irc.domain.com but they all point to diff servers, and usually the server that you are directed to is the closest to your ip

hope that helps

OutHOST is partially correct, however the "usually the server you are directed to is the closest..." is not entirely accurate. What you're referencing there is geoIP location based DNS services. A RR address is just that a truly random address.

OutHOST is partially correct, however the "usually the server you are directed to is the closest..." is not entirely accurate. What you're referencing there is geoIP location based DNS services. A RR address is just that a truly random address.

You're right, Justin. Extending that line of thought, if the same user (computer) tries to connect to the round robin DNS hostname again, will he be connected to a different random server, or is the original server's IP address still cached from DNS and re-used by that user?

-mike

You're right, Justin. Extending that line of thought, if the same user (computer) tries to connect to the round robin DNS hostname again, will he be connected to a different random server, or is the original server's IP address still cached from DNS and re-used by that user?

-mike

that depends on the users workstation setup, from my experience it will usually try a different ip but i have some times seen it use the same, also depends on which ip the dns servers give out

No it depends on the TTL of the DNS record. Set it really low so that it ISN'T cached for very long. Essentially you are going to ask DNS far more frequently for the ip assignment and that is what allows for the failover / VERY rough load balancing to work.

hey, how to have this? i'm not too sure. say i got two servers/ip.

then, i'll just create two A Record for irc.domain.com.
irc.domain.com A 1.1.1.1
irc.domain.com A 1.1.1.2

two A Records? so when will the visitors go to .1? when they will be go to .2? or it will just randomly throw them into those two ip?

hey, how to have this? i'm not too sure. say i got two servers/ip.

then, i'll just create two A Record for irc.domain.com.
irc.domain.com A 1.1.1.1
irc.domain.com A 1.1.1.2

two A Records? so when will the visitors go to .1? when they will be go to .2? or it will just randomly throw them into those two ip?

Yep, pretty much - it'll be random.

Correct me if i'm wrong while RR might be working in some cases, but for a website it will still send 'visitors' to the IP even if the server is down, making your website unreachable for those who where unlucky of getting the down server IP from the pool. Not sure if that is the solution you are looking for.

You might want to look at Edgedirector.com (http://www.edgedirector.com) services.

There are a number of considerations that come to mind when managing a pool of servers.

First, let me state that I know nothing about the requirements of irc in particular as regards sessions and stickiness.

Having said that, there are two approaches to this sort of thing. The differentiating factor is the location of the servers.

If the servers are in the same physical data center, then a hardware load balancer is usually the best solution.

If the servers are in different, preferably far apart, data centers, then geolocation capable DNS is the better answer. The reason I say far apart, is that the user may as well benefit from an improvement in latency when pointed at the nearest server. This happens when they are farther apart, and hence each has a user population that is "local" to that server.

If the server placement is a hybrid of the two mentioned above, for example, four servers arranged as pairs of servers in two data centers, then the ultimate setup is geolocation aware dns pointed at two hardware load balancers. BTW, this is a big part of the Akamai solution. There is more, but that is out of scope here.

The public NTP server project worked on this a couple of years ago for pool.ntp.org which is really many NTP servers spread around the globe. They had some difficulty because of the DNS software they were trying to use. The final outcome was never published.

In geolocation aware dns, the authoritative dns servers have multiple A records, but hand out only the best record when asked for the A record, or a related CNAME.

As far as ttl, round robin and randomness, the theory goes that the caching dns server will tend to take the best record based upon response time. This is not guaranteed behaviour and is non-deterministic. It depends completely on the inner workings of the particular cache and is not specified in any RFC that I know of. It is simply an observation made by some knowledgeable people in the past.

have A reconds with no big TTL would work more than fine in most cases (lets say 95%)

Correct me if i'm wrong while RR might be working in some cases, but for a website it will still send 'visitors' to the IP even if the server is down, making your website unreachable for those who where unlucky of getting the down server IP from the pool. Not sure if that is the solution you are looking for.

You might want to look at Edgedirector.com (http://www.edgedirector.com) services.

With IRC, it picks the server that replies fastest and you connect to it. It will never connect you to a "down" server.

With IRC, it picks the server that replies fastest and you connect to it. It will never connect you to a "down" server.

What do you mean? That's not really correct if I'm reading it right...

What do you mean? That's not really correct if I'm reading it right...

What "should" it be?

in an IRC round robin, if you have 18 servers added, you will never go to the one that's down

What "should" it be?

in an IRC round robin, if you have 18 servers added, you will never go to the one that's down

There's no difference between a pool of A records and an "IRC round robin." The DNS server (and most IRC clients that I know of) won't check that the address is connectable before handing it to you.

There's no difference between a pool of A records and an "IRC round robin." The DNS server (and most IRC clients that I know of) won't check that the address is connectable before handing it to you.
I'm aware there's no difference. I have had a network of 4 leaf's connected to a hub, two of the leaf's went down (99% of the time I end up on one of those leaf's). I connected, and ended up on another server without any failures.

I'm aware there's no difference. I have had a network of 4 leaf's connected to a hub, two of the leaf's went down (99% of the time I end up on one of those leaf's). I connected, and ended up on another server without any failures.

Coincidence or cache. There's no checking implemented on either protocol by default.