[Top][All Lists]
[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