#132 Payload: Compression

9.9.9.9: Backlog
wont-fix
nobody
None
2021-10-23
2021-03-31
i-campbell
No

There is a non-normative compression practice in the Tahu project.
https://github.com/eclipse/tahu/blob/develop/client_libraries/java/src/main/java/org/eclipse/tahu/util/PayloadUtil.java

Essentially, you
1. compress the payload to an array of bytes using GZIP or DEFLATE.
2. This array of bytes is put in the payload.body.
3. Optionally, a single payload.metrics named "algorithm", of datatype String contains the string_value either "GZIP" or "DEFLATE". If this is not included, then "DEFLATE" will be assumed.
4. paylaod.uuid contains the text "SPBV1.0_COMPRESSED"

eg.

{"timestamp": 16000000000,
 "metrics": [{"name": "algorithm",
              "timestamp": 16000000000,
              "datatype": "String",
              "string_value": "GZIP"}],
 "seq": 12,
 "uuid": "SPBV1.0_COMPRESSED",
 "body": <GZIP compressed bytes of the actual payload>
}

or

{"timestamp": 16000000000,
 "seq": 12,
 "uuid": "SPBV1.0_COMPRESSED",
 "body": <DEFLATE compressed bytes of the actual payload>
}

Discussion

  • hermsen

    hermsen - 2021-07-25
    • zipping and uzipping don't seem a normal PLC task. Maybe we could off-load this to the OS or something?
    • Hardware supported compression;
      plusses are myriad like optimised CPU usage, so hardly any loss of performance.
      minus: CPU must support it and needs a special dedicated library which enables it.
    • Softeare supported encryption; Plus Any CPU can encode/decode payloads of arbitrary length. Minus: The encoding and decoding will take a fair bite out of the Runtime performance.
    • I personally feel that software compression doesn't weigh up against bandwidth saving gains. I'd opt for hardware supported compression or none at all.
     

  • hermsen

    hermsen - 2021-10-23
    • labels: Payload -->
    • status: open --> wont-fix
     

Log in to post a comment.