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

[wolpers]

On Fri, 2002-11-15 at 21:35, Daniel Ng wrote:
> 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?

Yes, only the MASTER does need a complete list of gameservers (*) since
he is the one clients will ask for the list.
I am not sure if we are talking about the same issue here.  The antbear
MASTER will keep a list of gameservers together with detailed
information on each gameserver.  Normally gameservers would register
themselves at the master so that clients will actually be able to find
that gameserver.  This of course will only work if the gameservers do
know about the antbear.  On the internet this is probably not going to
be the case, so we need to get the list of gameservers from another
resource - an official masterserver that is.

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

I do not expect this to become a problem.  We should, and that is the
best practise to my knowledge, place GUI-initiated work in a separate
thread.  This thread would then be started once the button is pushed. 
If this thread disables the button right after start and enables it
again when finished the user will not be able to start multiple threads
trying to do the same work.

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

I can see clearly now.

- Thorsten