Re: [Antbear-devel] Class Diagram 1st draft done & Threads

[Thorsten Schemm]

Hiho,

> 
> Multi-Thread stuff:
> 
> So, do we agree on the following?-
> 
> -1 thread to handle interactions with connected
> Master/Supporters (or 1 thread for *each* connected
> Master/Supporter??)

First option.

> 
> -1 thread to handle interactions with connected
> Gameservers (or 1 thread for *each* connected
> Gameserver??)

We need to distinguish between querying gameservers (active)and
answering gameserver requests (passive) like when a gameserver registers
itself at the master or when the gameserver gives a heartbeat. 
(note to me: I need to look into this protocol sometime).

Yes, the 'passive part' should be treated by one thread only I would
say.  Just like the MASTER/SUPPORTER handling.

Details on the 'active part':

Let me explain the way I would do it the 'old fashion way' without using
the nio classes.  When using the nio classes things might change a lot,
but you are the expert on that subject 8) .
Not using nio I would use one thread each gameserver.  In searchtool I
do query the gameservers like this to avoid too much overhead that would
be caused by actually creating a new thead for a new gameserver:

1. place all servers in a stack(vector,list,whatever)
2. create a certain amount of threads, depending on the internet
connection (40 threads is the default in searchtool)
3. now let every thread grab a server from the stack and process it.
Once that one has been processed, grab another one, if there still are
servers left. A query does not do much work, but it is waiting most of
the time for a response, so not using multiple threads would lead to a
great loss of performance.

> 
> -1 thread to handle listening to and dealing with
> existing Gameclient connections, and listening for new
> connections of ALL types (ie.
> Gameclient/server/Antbear)

 I hope I got you right here:
One thread listening for all types of connections seems good to me.  But
there is another thread (the engine) that does the processing, whatever
request came in. Correct?

> 
> -1 thread to handle the GUI interactions.

Yes.  We should collect some ideas some time about the GUI and what we
should be able to control with it.  The range goes from displaying
statistics to being able to manually kill connections.

> I guess we need to know what is the maximum/typical
> size of the player lists downloaded from a Gameserver?

Well, there is no real maximum.  But we could set one because there will
hardly be any servers with more than 62 players on it.  The average will
on a full server would be 16 to 20 players on one server.  Of course
there will be a lot of empty servers.

> What is the max/typical size of player lists
> downloaded from a Supporter? From a Master to a
> client?

I have no idea yet about the size of a list we transfer between MASTER
and SUPPORTER.  We have free hand here.
The max list from a MASTER to a client would be around 30000 servers
nowadays.  Half a year ago that used to be around 25000, so the number
might increase.  Thanks to the MASTER <--> client protocol we can send
the list in pieces.
I could not say if there is a typical number because the size of the
list depends on the specified filter.

> 
> 
> 
> Mutex- 
> 
> (Just to confirm, we will still need synchronisation
> mutex stuff on the databases because you could
> manually delete a peer connection via the GUI while at
> the same time the Server was getting Gameclient
> information from that connection.)

I did not get this, but it is late here 8) . I will have a closer look
on this tomorrow.

> 
> 
> These questions may affect the Class Diagram so better
> that we resolve them before we move on to coding,
> etc.-do you think so?
Well, I can't tell since I could not yet have a look at the diagrams due
to my professional skill in nuking operatingsystems.
Good night,

- Thorsten