As per the 6.1 or so changes to introduce Oodle compression. There's a few options here and I'm not sure what's best, leaning towards an interface for decompressors and allowing it to be user's choice. The following are what I had in mind:
LLVM IR from open source Oodle implementations, calling LLIR functions directly
Transparent eBPF decoding/encoding with kizer's helper
CGO directly hitting Oodle dynamic library (third party dumps of the Oodle DLL)
Native Go implementations of Oodle (there's a few around, none great, but we only need enough support for FFXIV)
eBPF is particularly interesting, effectively allowing the Linux kernel network stack to decode packets on receive and re-encode them on send, so anything using the data has full access without any compression in the way. The downside is that it only runs on Linux as eBPF doesn't exist on other platforms unless you count BSD separately.
LLIR is likely the most simple to use and maintain even though it sounds really weird, the downside is that it loses all of the ASM optimisations the official Oodle static lib has, but those might be trivial and third party libs lack them anyway.
As per the 6.1 or so changes to introduce Oodle compression. There's a few options here and I'm not sure what's best, leaning towards an interface for decompressors and allowing it to be user's choice. The following are what I had in mind:
eBPF is particularly interesting, effectively allowing the Linux kernel network stack to decode packets on receive and re-encode them on send, so anything using the data has full access without any compression in the way. The downside is that it only runs on Linux as eBPF doesn't exist on other platforms unless you count BSD separately.
LLIR is likely the most simple to use and maintain even though it sounds really weird, the downside is that it loses all of the ASM optimisations the official Oodle static lib has, but those might be trivial and third party libs lack them anyway.