antbear-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Antbear-devel] Usecase discussion- detailed


From: zoidberg
Subject: Re: [Antbear-devel] Usecase discussion- detailed
Date: Sat, 02 Nov 2002 12:21:39 +0100

Daniel Ng <address@hidden> schrieb am 31.10.2002, 17:07:57:
> Hi Thorsten and Adam,
> 
> A few more questions/observations:
> 
> 1) The FeedMaster function- to minimise traffic and
> therefore minimise processing, the Supporter should
> only send updates to the Master every x seconds, where
> x is defined by the Master. x is communicated to the
> Supporter when the connection between Master and
> Supporter is first initialised. Do you agree?

What I am not sure about is whether the SUPPORTER or the MASTER should
define the 'x' .  If the MASTER does it connecting supporters have less
options on configuring their antbear depending on their internet
connection or their bandwith(maybe not correct term) they are willing to
provide.
One thing that just comes to my mind is that if the MASTER wants to
check the incomming data for correctness the data has to be as 'fresh'
as possible.  So if the SUPPORTER would have the option of defining a
large 'x' the MASTER could end up receiving outdated data.  
We would have to make sure that the SUPPORTERs would collect the data
just before a new update of the MASTER antbear.  This would make
'little' supporters idle for some time but that is ok to me.  
I would also say that there should be a fixed number of gameservers that
should be checked in an interval(x). 
> 
> 2) Clarification of terms- 
> 
> a)'Antbear' can be either a Master or Supporter or
> both. Correct?
true
>  
> b)'Antbear' is *not* a half-life Gameserver. It is
> more like a Communications Tool. It may reside on the
> same machine as a Gameserver, but this is not
> necessary, as long as it can reach the Gameserver.
> Correct?
true.  Antbear should be a half-life masterserver that provides clients
with serverlists that can be limited by providing antbear with a filter
(map/mod/playername/...).  
To make sure antbear can reach the gameservers they would either have to
register themselves at the antbear on their own (which is not very
likely because no gameserver is going to know an antbear IP) or antbear
copys a list of an official masterserver.
> 
> 3) A Master can collect its data directly from
> Gameservers, as well as from Supporters?
true.
> 
> 4)What does PerformSecurityChecks do? ie. what is
> defined by a 'correct' incoming result? Should a
> Supporter also do this check on data from its Masters
> and Gameservers?
Well, the MASTER receives some data on gameservers from a SUPPORTER  and
depending on the level of security the MASTER is using(*) it has to
query the same gameservers and compare his own data it can trust with
the potentially wrong SUPPORTER information.  We need to think of a way
to compare this fast changing data without blaming a supporter of being
an evil antbear just because the data actually did change.  If we cannot
come up with a solution to that quickly we can just leave those out for
the beginning but we should plan such a function in our diagrams for an
easy update later.
(*) The level of secutity could be tweaked by making SUPPORTERs trusted
or untrusted(default) and the number of incomming updates to be checked
(like checking one out of ten incomming updates, independent from the
SUPPORTERs).  If somebody is good in maths we could find some rough
numbers that tell us the probability(correct term?) of detecing an evil
SUPPORTER with certain settings.

The SUPPORTER can trust the gameservers because he has no choice.  A
gameserver is the only one that can hand out information on himself. 
Also a SUPPORTER should safely trust his MASTER because he chose to
connect to the MASTER, and he pretty much decides what tasks to perform
on its own.  So I see no risk there.
> 
> 
> I guess after we clear up these questions and any
> other questions you guys may have, we should then
> update the UseCase diagram. Then we can start on
> design docs such as class diagrams, data dictionary
> and architecture...
> 
I agree.

- Thorsten

> Daniel.
> 
> 
> __________________________________________________
> Do you Yahoo!?
> HotJobs - Search new jobs daily now
> http://hotjobs.yahoo.com/
> 
> 
> _______________________________________________
> Antbear-devel mailing list
> address@hidden
> http://mail.nongnu.org/mailman/listinfo/antbear-devel




reply via email to

[Prev in Thread] Current Thread [Next in Thread]