Mathias Fröhlich wrote:

>What is missing is a clear architecture indenpendent definition of the storage 
>layout....
>Also a 'protocol version' field in the message header will be a good idea IMO. 
>That way clients could distinguish if and how they should look at that binary 
>chunk.
>  
>
The version field is a good idea. And I have another suggestion. There
should be a "info" packet, containing details of the client. I'm not
sure what information should be sent to call the packet "complete", but
I have some  ideas of what should be included anyway:

1) The aircraft (name) a client is using (it isn't nessecary to send
this information with every packet)
2) A "visibility" range (Vivian called it "Radar Echoing Area"),
provided by aircraft model data. That way a eg.  747 can show up on
radar earlier than a cessna, making radar more real.
3) A radio transmission range, i.e. the range a client is able to reach
via radio when sending (voice) messages
4) A radio receive range, i.e. the range a client is able to receive
messages from. This may also be aircraft specific, not sure about that.
5) the frequency a client is listening to (erm, there are two listening
frequencies, right?)
6) the sending frequency of a client

There is probably more information needed. However, the network protocol
has to make sure that this information is received by others, that means
there should be some confirmation mechanism on received packets, at
least for these info packets. My suggestion for this is:
1) The info packet contains random "packet number"
2) The sender resends the packet until it receives an
"acknoledge"-packet from the receiver (another client or fg_server),
containing only the "packet number" and a string "ackloledged".

An info packet must be sent if any information is changed, e.g. a client
switches frequencies or whatever.

Opinions?

Oliver

_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Reply via email to