From: Thorsten Schemm <address@hidden>
To: address@hidden
Subject: Re: [Antbear-devel] Architecture questions
Date: 12 Nov 2002 01:36:59 +0100
On Mon, 2002-11-11 at 22:35, Daniel Ng wrote:
> Hi guys,
>
> I am working on the Class Diagrams, should be able to
> provide an initial one tomorrow (Tuesday).
cool
> Are we planning on making this multi-threaded? I think
> it will start to get complicated, especially with
> controlling mutual exclusive access to the databases.
>
> Perhaps we start coding a single-threaded prototype,
> but have 2 different designs- for single and
> multi-threaded?
see answer below.
>
> I believe we will still need a multi-threaded program
> because the non-blocking nature of Java nio only means
> that the Server will still be able to 'hear' all
> Clients, even when it is already 'hearing' a single
> Client. However, once the Server starts processing
> this single Client's request, it will not be able to
> Process the other Clients' requests until it is
> finished with the single Client's request. So we need
> to make this Process a thread, right?
Yes, this process has to be a thread. That is, we have a thread for
listening, and a thread for processing the requests (correct me if i
conflict with the NIO technology).
The thing is, I do not know if it would make any sense if we use
multiple threads for processing the clients' requests. The only
noticable 'work' antbear does to work on a request is accessing the
database. So I am not sure if we would gain any performance if we allow
multiple requests to be worked on at the same time since they all would
wait at the database, which is the bottleneck. Am I wrong?
Of course there should more threads for updating the database and doing
all the SUPPORTER/MASTER work (one each). So all in all there will be
multiple threads, the only question there is is whether we use more than
one thread to process requests from clients. At least that's what I
think.
>
> Thorsten, you want to use a free-software version of
> the JVM, but would there be any that support Java nio?
Well, any VM that makes use of the 'classpath' project should be capable
of using nio (AFAIK!). But to make things easy for the startup let's
use the SUN and/or IBM machines for developing. We can than test the
code once in a while with other machines and might do a few code changes
then. Those changes should not affect the structure I expect. Let's
make the antbear walk, first 8) .
But let us target our code to run on any 1.3.0 Java Virtual machine and
above. So we should not make use of any 1.4.x features except the nio
classes of course. I mention this because the classpath project is not
really moving at lightspeed 8)
>
> Finally, do we need to develop an Antbear Client as
> well? Do the HalfLife Gameclients already know how to
> communicate with a Masterserver, and already have a
> standard protocol for this, or will we need to make
> this too?
If we are able to clone the halflife protocol (masterserver <-->
gameclient) gamers should be able to connect with their clients to
antbear without even noticing a difference. Since every other
gamebrowser uses just the same protocol there should not be a problem
there. The only thing no client(so far) will understand is how to get a
list of servers by specifying a playername. As soon as we get that
going I will place this support into searchtool (
http://searchtool.sourceforge.net ) so we have a tool to test our
protocol. The protocol between masterserver and (game)client is pretty
well documented in the attached file. The documentation is intended for
developers of gamebrowsers that do want to query the masterserver but we
should be able to create the proper UDP packeges with that knowledge.
PS: Just ignore the part in the attached file that is about other games.
The second half should be quite informative. I have another file, but
that one is in german, so I will translate it and send it to you guys
later.
- Thorsten
<< QueryingGameServers.txt >>