VROC: Virtual Racers' Online Connection

Development Notes

Continued

Part 1 | Part 2

GPL Spy Boy and GPL Disconnects

4/14/99 - Recently some people have become concerned about connection problems. Some feel that these problems are worse since GPL Spy Boy was released.

Here's Alison's take on this issue:

Is GPL Spy Boy causing disconnects in GPL races on VROC?

I don't discount that people are having connection problems. However, we haven't yet received any hard evidence that this is caused by GSB or VROC. Knowing how VROC, GPL, and GSB work, I find it difficult to imagine that GSB or VROC could be causing these connection problems, but on the Internet, I suppose anything is possible.

Nevertheless, we are taking steps to ensure that the integration of GSB into the VROC software environment will have only a positive impact on the VROC community and races hosted through VROC.

A new version of GSB and VROC server improvements

In the last week, Larry has been working hard on a new version of GSB which is more efficient and will further reduce the load it puts on both the VROC server and GPL hosts. I have been reworking the server side of VROC to make it more efficient as well.

Many of the server enhancements are already in place, and others will come online with future releases of GSB and the VROC Java applet. A new release of GSB is being tested as I write this, and barring unforseen problems should be ready for release within a matter of days.

How GSB, VROC, and GPL hosts interact

As you know, when you join a race through VROC, you are connecting directly with the race host's computer, and VROC and GSB drop out of the picture until you leave the race and return to either Netscape and the VROC applet, or GSB. The only way GSB could possibly impact you is through other copies of GSB running on other peoples' computers, in that those copies of GSB might be pinging the host you are connected to.

Although I consider it unlikely, it's conceivable that the extra load caused by GSB's automatic refresh and its associated pings to GPL hosts could be triggering more disconnects. However, these pings are discontinued before the host goes into race mode, so GSB could not possibly be triggering disconnects during races, only during practice.

The current version of GSB, version 95, pings less often than the original version. The original version is no longer functional; we disabled the VROC server components that it talks to, and anyone using it will get only an empty race list. So you don't have to worry about the original version of GSB causing problems.

The next GSB

The upcoming version of GSB will ping GPL hosts even less often than version 95, and it will cease pinging a GPL host well before the GPL host begins to enter race mode. This should completely eliminate the possibility of GSB having anything to do with disconnects during the transition period between practice and race. It should reduce the likelihood of GSB causing disconnects during practice to an extremely low level.

This new version of GSB will be highly configurable from the VROC server, so we will be able to adjust GSB's ping rate (and tune other GSB behaviors) to optimize performance.

Other possible causes of disconnects

Larry and I both feel that the most likely connection between GSB and GPL disconnects is indirect: It's clear, from watching the race lists, that a large number of additional people have begun participating on VROC since the release of GSB. I believe this is due to GSB's excellent user interface.

This is terrific, but we suspect that many of these new users have neglected to read the advice posted on VROC and my Eagle Woman site about optimizing their DUN, utilizing the correct core.ini, and setting up their computers to get adequate frame rate in GPL.

Failure to do these things can have a significant impact on connection quality, particularly in the case of people who are hosting, where an overloaded GPL server or server upload link will impact everyone in the race. Hopefully these new folks will quickly realize that they need to take steps to ensure that their computers and their Internet connections are performing adequately for racing online.

It's also possible, as others have pointed out, that additional Internet traffic from Star Wars, Kosovo, or sun spots <grin> is impacting our racing. Hopefully the Star Wars stuff will peak soon and the Internet will get back to normal.

The next generation

Larry has devoted a huge number of hours in the last week to this project, and it's consumed a great deal of my time and energy as well. Nate has been working very hard since before Christmas on a superb new Java applet which will support the GPL patch.

Changes we've made on the server in the last week as a result of what we've learned since the introduction of GSB will make the new version of VROC even better. Although it has created some challenges in the short term, I feel strongly that the release of GPL Spy Boy has been a very positive development for the VROC community.

We are working towards what we believe will be a much better online racing environment for everyone. Thanks to everyone who has been hanging in there!

VROC Server Enhancements

4/14/99 - The original version of GPL Spy Boy exposed a problem with VROC's server design which was previously not apparent.

This was because GSB made many more requests for race lists than the original VROC Java applet. While the VROC applet polled the VROC server and requested races lists only when the user clicked the applet's Refresh button, GSB polled the VROC server and requested race lists automatically once per minute. Further, GSB made three requests per minute, one for each of VROC's three race rooms.

Because of GSB's instant popularity, this additional workload quickly swamped the VROC server, bringing VROC and all other Gamestats sites located on this machine to their knees. The Gamestats sysadmin was forced to disable VROC.

Quick fix

We quickly reworked the VROC server software and GSB to require less frequent requests. A day after the release of GSB 92, the GSB 95 patch was released. This version polled the VROC server at a much less frequent interval, initially once every 180 seconds, later reduced by a control on the VROC server to once every 90 seconds.

Changes to the VROC server-side software allowed GSB to retrieve data for all three rooms in one request. In addition, we implemented a new way for GSB to retrieve the race list data.

The old way of retrieving race lists

The VROC applet and the original version of GSB retrieved the race list by making a request to a CGI script on the VROC server. Each request caused the Gamestats Web server to launch a Perl interpreter, which ran the Perl CGI script, which in turn accessed the VROC database and returned the list of races.

This worked fine in a low-volume environment, but we now realize that it was placing much more load on the Gamestats machine than necessary. We devised a different mechanism through which GSB could retrieve the data more efficiently.

New race list service for GSB

Now, a background process on the VROC server queries the VROC database every 30 seconds, and retrieves a list of all races. It then writes these races to a text file. When GSB requests a list of races, the Gamestats Web server needs to merely retrieve and send back the text file, an operation which has much less overhead than launching a Perl interpreter and executing a Perl script which in turn accesses the database.

The improved efficiency should allow us to increase the frequency of the revised GSB's automatic race list requests to nearly as often as the original GSB, while placing much less load on the Gamestats server than the original version.

We're taking a conservative approach on this because - among other things - we don't want to tax the patience of the Gamestats sysadmin, who has been wonderfully helpful and supportive despite the problems we caused him. The last thing we want is a repeat of the overload situation we encountered the night of GSB's original release.

Improved race list quality

While making these changes, we also implemented some changes which improve the quality of the race list. For both GSB and the VROC applet, we no longer report races which are in Starting mode (i.e., which have not yet reached the point where they are responding to GPL queries).

We also no longer report races which we think have become stale. GPL 1.0 does not respond to queries once a race has started. It does not resume responding until the host exits race mode and returns to Waiting mode (i.e. the Track Selection screen) or Practice mode.

As you have probably noticed, VROC reports a number of minutes remaining in races that are under way. It does this by estimating how long a race should take, based on the number of laps at the given track for the race type (Novice, Int/Pro Short, Int/Pro Long), multiplied by a reasonable lap time (derived from GPL's reference lap time for that track), and with a few additional minutes added for chatting at the end of the race.

Since this estimation is done on the server, we can select records which are either in Waiting and Practice mode, or which we believe are probably still racing. Once our estimate of the number of minutes remaining for a given race goes below zero, we no longer report that race.

Sorting

We've also begun sorting the race list sent to the Java applet so that Waiting and Practice races appear above those which are Racing, and those with faster connections appear above those with slower connections.

This gives a list order which is fairly similar to the list reported in GSB (this has an internal sort which also sorts on ping times). It also ensures that races which are unavailable because they are in Racing mode will not hide races which are in Waiting and Practice mode, something which could otherwise happen because of the VROC applet's display maximum of nine races.

More Reliable Race Launching

Sometimes people would host races on VROC, but their race status would never advance past Starting. This was particularly noticeable with GSB, but we believe it was happening with the VROC applet as well. Larry's testing highlighted this problem and pointed to a solution. Ironically, the VROC 1.2 applet, currently in pre-alpha testing, was also suffering from this problem.

We've fixed this problem and now races launched through either the VROC applet or GSB should be displayed once the host advances to the Track Selection screen. As a side benefit, GSB should lauch races more quickly, and both GSB and the VROC applet should reload the race list more quickly when the user returns from GPL.

Future

The current VROC applet was never intended to be a finished product. It was a concept which was quickly rushed into production in order to get minimum functionality operational as soon as possible after the release of GPL.

A much more sophisticated applet has been under development by Nate Hine for several months. This applet implements auto refresh, scrolling and sorting of the race list, setting of numerous race options on the applet itself, support for Microsoft Internet Explorer, dedicated GPL server support, automatic optimization of GPL bandwidth parameters on both clients and servers, and a number of other advanced features.

This new applet is tightly integrated with the upcoming GPL 1.1 patch. It won't function with the original release of GPL. As soon as Papyrus releases the GPL patch, we'll go live with the new VROC 1.2 applet. An enhanced version of GSB with GPL 1.1/VROC 1.2 support will hopefully be available within a short timeframe.

We are also working on an even more low-overhead mechanism for communications between the VROC clients (both VROC 1.2 Java applet and GSB) and the VROC server. This new mechanism should allow us to cut the Web server out of the loop entirely, further improving VROC client-server communication efficiency.

Additional features are under consideration, including VROC participant tracking and support of additional racing simulations.