On 17/04/2013 14:17, Max Kellermann wrote: > However, we don't use TCP for a good reason - TCP requires a three-way > handshake, and that's often not possible with flaky networks.
I was thinking about the "catch up" transaction. One TCP session could be used to report the missing data to XCSoar and then for XCSoar to re-transmit the data block to the logging server. At least at this stage one would have the benefit of error detection. >> PS: Is there any compression of the data before it is sent? > No. It's hard to imagine how 48 bytes can be compressed. However it > would be possible to implement a smaller "GPS fix" datagram by > omitting many of the rarely used fields (like "airspeed" or "ENL"). > Maybe we could go slightly below 40 bytes, but I'm not sure if that's > worth the trouble. Once again, probably not worth it for logging live traffic, but may be worth considering for "catch up" traffic, which could entail quite a lot of data in a single upload. If you want to compress the live traffic, you could look at a protocol like "Van Jacobson" compression as described in rfc1144 http://tools.ietf.org/html/rfc1144#page-4 This is for compression of TCP/IP headers, but you could use a similar principal for compressing, say, the most significant characters in GPS co-ordinates, which wont change from fix to fix. Regards Ian ------------------------------------------------------------------------------ Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter _______________________________________________ Xcsoar-user mailing list Xcsoar-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xcsoar-user
