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. |