Re: [Antbear-devel] performance architecture- threads (Warning- long!!!)

[Daniel Ng]

On Fri, 2002-11-15 at 00:15, Daniel Ng wrote:

<snip>

> If an Antbear wanted to make new connections to
> multiple Gameservers, this is what would happen:
> 
> 1) List of Gameservers obtained from
> GUI/(commandline?)
... plus (optional, but per default ON I would say) a
list cloned from
an official masterserver, if the antbear is running on
the internet and
not a LAN .

[DAN SAYS:] 

But why would we need to do this, unless you are
saying this is a second
Master which needs a complete list of Gameservers?
This is because only
the Master needs a complete list of Gameservers,
right?

> 
> 2) The GUI has its own Select Key registered with
the
> continuous select() loop in ConnAdmin. This key was
> initialised to have an object attached to it. GUI
> tells AntbearEngine it wants to register new
> Gameservers. AnbearEngine configures the object to
> 'registerNewGameservers', including a list of all
the
> new Gameservers. AntbearEngine fires this key (by
> writing to a Pipe which is linked to the key- **Is
> this the best way to do inter-thread
> communications???). 
I do not know, need to think about that.

> This entire step is done in the
> GUI thread. 

nanana, no work in GUI thread .  We have to place that
work in a
separate thread (maybe anonymous, whatever).  Any work
in the
event-handling thread would block the GUI from
repainting which is 
quite
ugly for the user.  
(I figured GUI-thread == event-handling thread. You
might have seen 
that
different, in which case this comment was a waste 8)
 
[DAN SAYS:] 

Oh! Of course, you are right. Very good point. Maybe
we call the 
second thread the "GUI2" thread, since all it does is
handle 
actions requested from the GUI. 

Then again, won't the above activity be so quick that
the user 
won't notice anyway? The disadvantage of having a GUI2
thread
is what happens if the user presses a GUI button many
times 
quickly? Would this cause GUI3, GUI4, GUI5, etc.
threads, or
do we use the same GUI2 thread for everything? If we
use the
same GUI2 thread, this will make the program more
complex becuase
we will need more inter-thread communications. If we
have GUI3,4,5
threads, then what happens when we run out of threads?

Maybe it's better to keep it simple and stick to 1 GUI
thread
which does the GUI-initiated work as well?

> 
> 3) AdminConn.Select() detects the key has been
fired.
> It looks at the key's attached object, which tells
it
> to 'registerNewGameserver'. Hence, it attempts to
make
> connections to the new Gameservers. At this point,
> connect() returns immediately, so that all the new
> connection requests are started without delay- ie.
no
> blocking. This is all done in the 'connecdtions'
> thread.

Please define what is a 'connection'.  The whole
protocol is based on
UDP (connectionless) which makes me a little confused.

[DAN SAYS:]

Sorry, you are right again, I was wrong in thinking in
terms of TCP.

So the above should instead be:

3) AdminConn.Select() detects the key has been fired.
It looks at the key's attached object, which tells it
to 'registerNewGameserver'. Hence, it attempts to make
connections to the new Gameservers by writing to the 
new remote socket. At this point, write() returns
immediately, 
so that all the new connection requests are started
without 
delay- ie. no blocking. This is all done in the
'connections'
thread.

So there are still 'connections'- they are Application
Layer
connections, not Transport Layer (UDP) connections. It
is an 
Application Layer connection because our code must
remember
the state of the connection eg. 'sent request for rcon
challenge'
or 'received rcon challenge number', etc. This state
will be stored as 
an attribute in the ABConnection object. I need to put
it 
in the Class Diagram...

(Steps 4 & 5 should remain the same)

<snip>

__________________________________________________
Do you Yahoo!?
Yahoo! Web Hosting - Let the expert host your site
http://webhosting.yahoo.com