antbear-devel
[Top][All Lists]
Advanced

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

Re: [Antbear-devel] Added to Activity Diagram, and more discussion...


From: wolpers
Subject: Re: [Antbear-devel] Added to Activity Diagram, and more discussion...
Date: 29 Apr 2002 08:21:17 +0200

Hello people,
let me try to comment on your changes, there was a party at my
university last night and i just got up (4.45 PM) so I am blessed with a
huge hangover 8) .

On Thu, 2002-11-07 at 00:56, Daniel Ng wrote:
> Hey guys, I just checked in a new version of the .vpp
> and .txa files-
> 
> I have added to the Activity Diagram the activities
> related to Registration of new Supporters. I know it
> doesn't really fit in the 'DatabaseUpdate' Activity
> Diagram because the Supporters should be in a
> different database to the Gameservers, but since we
> only can do 1 Activity Diag per Project, I thought
> this would be the easiest workaround.

When naming the activity diagram I forgot that we are limited to one
diagram per UML type.  So I think we should (I did)name the Diagrams
different and also we should place all diagrams we would have set up in
a separate diagram in the same one by using more initial/final states. 
I did this with Daniel's activities already, so check that out to see
what I mean.

> 
> Not sure if there is a need for any more additions to
> the Activity Diag, since the Use Cases not in the
> Activity Diag are too trivial to put in there. What do
> you think?

That's fine, we probably can extend things later if we come up with some
new stuff.

> Except for one thing- have we considered the
> DEregistration of Supporters (I know we have already
> capture the deregistration of Gameservers)? Would this
> be necessary?
Good point that is.  I mentioned it in the use-cases as an extending
usecase to the security checks.  If a supporter has been prooved of
sending false data it would then be banned.  
I now extended the documentation tag so that a SUPPORTER can now be
de-registered on its own will if it is going to disconnect or if it is
just no longer responding (crash/offline/...).  
> 
> Once we figure this out, I guess it's the Class
> Diagrams? 

I agree.  Now it is getting interesting.  One question to you guys I
have, though.  Do you want to set up more diagrams than
use-case,activity and class?  If you ask me we should be fine with those
three.

> 
> Anyway, just to let you know what I'm doing, I'm
> reading up on Java Nio, and thinking about what
> Classes to use considering Nio and the way the
> Half-Life Gameserver protocol works...

That's cool.  I wanted to figure out the Nio package once, but I turned
out to be too lazy.  So I can just learn from your code then 8) .

> 
> Another question- Correct me if I'm wrong, I think
> there will basically be 3 conversations- 
> 
> #1) between antbear Master and antbear Supporter
> 
> #2) between gameserver and antbear Master/Supporter
> 
> #3) between antbear Master and gameclients
> 
Japp.

> Should we use TCP or UDP for each one? I think xlife
> used UDP for #2 & #3... Do we care for lost packets?

We have to use UDP for #2 and #3.  We do not have a choice there, but we
do for #1. I am unsure what I do prefer.  If we would use UDP for #1 we
somehow should take care of lost packages so we do not accuse a
SUPPORTER to be offline just because we lost a package.
If we get a timed out package for #2 when doing a query we should retry
once I would say.
On #3 I would say we do not need to resend packages.  The gameclient
would just need to resend the request.  

> 
> We will need to make up our own protocol for #1 and
> #3?
We do for #1 but we should implement the already existing protocol there
is between 'official' masterservers and gameclients. The existing
protocol does not have a way to ask for servers with certain players on
it , so we should extend it in this case. 
We can get information out of the xlife sources and the text file that I
once sent you a link to.  I can resend it if you lost it.

- Thorsten






reply via email to

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