--- [EMAIL PROTECTED] wrote:
> ace project <[EMAIL PROTECTED]> writes:
>
> > I've attached a (Word generated) HTML-file with
> the
> > proposed protocols/headers to be used. Plz bomb
> them
> > :)
>
> I have only a few comments right now. More as I
> have time to delve into this further...
>
> 1. If you establish a TCP/IP connection, then
> provide a way to pass a
> "protocol version number" upon connection
> establishment. If using UDP,
> then a protocol version number should be passed
> in each packet. There are
> a few ways to do this:
>
> a. Add two extra bytes in the Level 1 or Level 2
> header. You likely don't
> want to add extra bytes, so the other options
> are probably better right
> now.
>
> b. Allocate 3 bits in FLAGS as a version number,
> with '111' reserved for
> versions greater than 6 (with some place to
> put them added later and
> known to exist because of the reserved '111'
> value.
>
> c. Allocate 1 bit in FLAGS to mean "initial
> protocol" (version 1.0). If
> not enabled, then the non-initial protocol
> must define where/how the
> version number is encoded. It should be well
> documented that any
> subsequent protocol version MUST define a way
> of specifying the protocol
> version number.
>
> If you don't provide for a protocol version
> number, you'll likely end up
> (in version 1.1 or 2.0) with things that you'd
> like to do but can't, while
> still maintaining backwards compatibility.
>
Version numbering per packet should not be necessary,
we will set the version that will be used in the
client-initialisation packet. This packet should not
change or be 'autodetect'. BTW client init should NOT
have compression...
Other version controlling methods are still under
consideration.
> 2. Providing only 12 bits of flags seems really
> skimpy to me. This isn't
> really an issue, though, when you add the
> protocol version number feature
> described above. If more bits are needed for a
> future protocol version,
> they can be added by that version.
>
> 3. FDM is declared as 50b in one place, and 20b in
> another. Ditto for
> Nickname.
>
> 4. Flight Dynamics Model as text sounds risky. What
> about having FDMs
> registered at FlightGear.org (with a numerical
> identifier assigned to them)
> and then just passing the appropriate FDM id?
>
> 5. Why is a termination character ('\r') required
> for plane and FDM when
> there's a length field provided? It shouldn't be
> necessary.
>
3,5:
We have not yet decided on this issue, we could use 1
length and then plit them up or (as defined atm) use
length field and split them up manually.
> 6. Eight players seems like a severe limitation. I
> can see the potential for
> hundreds of players. It would be nice to design
> the protocol such that
> there's no limit on number of players.
>
That would be easy, just send multiple packets of
player list, the only thing to add is a 'final flag as
in:
1. list 1-10 final=false
2. list 11-21 final=false
3. list 22-30 final-true
> You've got a really nice start here!
>
> Cheers,
>
> Derrell
>
> _______________________________________________
> Flightgear-devel mailing list
> [EMAIL PROTECTED]
>
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
__________________________________________________
Do You Yahoo!?
Yahoo! Autos - Get free new car price quotes
http://autos.yahoo.com
_______________________________________________
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
