To explain further, Lets say you have 3 web servers at 10.0.1.1, 10.0.1.2, and 10.0.1.3. These servers have a webserver and witango server installed on each. You have your dns set up so that 3 "A" records exist for "www.mydomain.com" for each of these IP addresses.
The easiest setup is to have each webserver only talk to the witango server on its own machine. This will work most of the time, but you will have problems of users losing session state. The reason this occurs is the way certain browsers/OS's cache DNS lookups. Most browsers will look up the ip for the domain, pick the first ip address, and cache it, and hit the same webserver for the whole session, causing no problem. Sometimes, especially with AOL, the browser will do a dns lookup many times in a session, and the first ip will be different then the first time it checked, which causes the browser to point to a different web server. When this happens, the witango server will start a new session, and all your session variables are lost, because they were on the first server.
The way to resolve this problem is to set the three witango servers up as a load group. So if the browser first points to server 10.0.1.1, and user variables are set, then three clicks later, it goes to the webserver at 10.0.1.3, the witango plugin will intelligently query each of the other witango servers in the group and find out if this user has a current session with any one of them. If it does, it will communicate with the appropriate witango server at 10.0.1.1, even though the request came through the webserver at 10.0.1.3. If the plugin checks the all the servers in the group, and there is not current session, it will pick one of the witango servers and give it the request.
The load group is a must, because it will allow your users to hit any of the webservers, but always go to the right witango server.
Also, another easy mistake to make is the setup of the clients.ini file. Here is the standard stanza in the default clients.ini file for the IIS 5 plugin:
[wiis.dll]
WITANGO_SERVER=127.0.0.1,18100
ERROR_HTML=C:\\Program Files\\Witango\\Server\\MiscFiles\\clienterror.html
REPORTCLIENTERROR=TRUE
Notice that it uses the "localhost" ip address to refer to the witango server on the same machine. When using the load group in the above scenario, you will need 3 clients.ini files for each plugin. You must not use the "localhost" ip address any more. All of the clients.ini files in the group must use the real ip addresses like so:
[wiis.dll]
WITANGO_SERVER=10.0.1.1,18100:10.0.1.2,18100:10.0.1.3,18100
ERROR_HTML=C:\\Program Files\\Witango\\Server\\MiscFiles\\clienterror.html
REPORTCLIENTERROR=TRUE
This exact stanza should be in each of the 3 ini files, and the witango.ini file should be modified to look like this:
VALIDHOSTS= 10.0.1.1:10.0.1.2:10.0.1.3
If you leave the 127.0.0.1 ip address in the clients.ini file when referring to itself, it will cause problems due to the way the clients determine if session state has been started on a server.
This is a lot of extra information, but I have been working through these issues for some time, and now have the system working flawlessly.
Robert Garcia
On Wednesday, January 8, 2003, at 05:02 PM, Dave Machin wrote:
Has anyone used DNS Round Robin as�a technique to load balance several WiTango servers?� If so, were there any problems?
�
Dave Machin
�
--
Robert Garcia
BigHead Technology
2781 N Carlmont Pl
Simi Valley, CA 93065
Phone 805.522.8577
http://www.bighead.net/
http://www.theradmac.com/
[EMAIL PROTECTED]
