20,741
edits
Improved J661 support: Difference between revisions
Jump to navigation
Jump to search
m
→Ideas
mNo edit summary |
m (→Ideas) |
||
| (3 intermediate revisions by the same user not shown) | |||
| Line 8: | Line 8: | ||
* i.e. avoid polling | * i.e. avoid polling | ||
* provide some form of push/pull support | * provide some form of push/pull support | ||
* use hashing | |||
= Ideas = | |||
** Handling multiple properties ** | |||
* One thing that would be great would maybe to be able to have more than one parameter to the output for the client in one telnet output (for example all the properties that have been requested), but even without that, performance should be far better than with polling I think. | |||
* For your information, in the ARINC 661 protocol, the User Application concatenates several "commands" in the same buffer, denoting each specific command by its ID (and in the case of ARINC, also it's widget ID, but it's not relevant to our problem). In our User Application implementation (which happens to be coded in C++), a lot of parameters which are considered as cyclic are send regardless of their value change, because they change often. However the Server checks for their change, and in this case, it does not go further than their decoding. It turned out that the time the Server takes to decode a huge buffer and make its checks is negligible (of the order of 1 ms for example). | |||
* However I need to check the number of parameters which should be sent to the Client in real scenarios. I don't think it's a lot, because ther is further logic in the Client itself, and it could be possible for the Client to unsubscribe for example when a display format is not presented anymore. | |||
* I was also thinking of supporting several parameters (and even return values) at once, my suggestion would be to still consider hex-encoding the UINT hash and then pre-pend it to each property value, the values could then be separated using a normal comma, so that we end up with a list of CSVs. | |||
* In addition, it might be worthwhile to consider pre-pending a UNIX timestamp to each server-side response, so that clients get some timing information, I guess? | |||
* The list of CSVs sounds good to me. And I agree that having the timestamps could be useful in some usecases. | |||
* supporting multiple values in one response (i.e. like CSV) will inevitably require server-side escaping and client-side "unescaping" of properties. | |||
== Hashing == | |||
* hashing is already supported by the property tree itself (see SimGear library), it is in fact used internally for storing properties, so one of the easiest ways to hashing support would be directly exposing and using the hashes computed by the property tree: http://simgear.sourceforge.net/doxygen/classSGPropertyNode.html It seems, the hash code is stored as an unsigned int (private storage), see line #01758 in http://simgear.sourceforge.net/doxygen/props_8hxx_source.html So it would just be a matter of adding the following to the public interface of the "bucket" class: inline unsigned int getHashcode() const {return hashcode;} And then add a corresponding wrapper to the top level SGPropertyNode class for accessing a node's hash. Either as a static method or as a member function using the "this" pointer. Something along these lines would then allow using hashes of properties internally, which would also reduce bandwidth requirements. | |||
= Patch prototype = | = Patch prototype = | ||
It turned out to be quite simple actually (as we anticipated already), so we have a working prototype ready. In its current form, it is still rather basic (i.e. no support for multiple properties or hashing), but subscribing and unsubscribing properties does work already. I prepared hashing support but didn't actually implement it fully. So it could definitely be enhanced rather easily if you think that'd be useful. I guess, it's now a matter of coming up with a list of changes that would be useful for j661, so that we can adapt the patch accordingly and submit it to the FG repository for review/inclusion. | |||
<syntaxhighlight lang="diff"> | <syntaxhighlight lang="diff"> | ||
diff --git a/src/Network/props.cxx b/src/Network/props.cxx | diff --git a/src/Network/props.cxx b/src/Network/props.cxx | ||