Features

​

Features include:

​

• Proleptic Inevitability. While archives may be corrupted in transit, their contents are not, because XQK adds a hard-shell contingency overlay to all archives (this overlay also serves to safely house the on-board algorithm). Furthermore, this scheme ensures that archives do not pseudo-putrefy during transit, which is possible when the transport protocol is BRTP, or if JPEG artifacts dominate.

​

• Extrospection. An XQK archive's on-board algorithm is aware of whether it is in transit across a network, and acts accordingly (see "Bilateral Serialization," "Subjective Packet Jettisoning," and "Intranodal Finalization" below). A side effect of the algorithm's awareness of whether it is in transit is that it is also aware of not being in transit when it's sitting still. Such an"at-rest" archive employs various power-saving measures (BDB registers powered down; Schoenenberger endopockets depressurized; Centax metashields exterrogated on a best-effort basis; etc.) when it determines that its Koroviev velocity is near-zero with respect to the local frame.

​

• Inlined PUMPing. Individual components of an archive may go missing during transit in the rare case of a Closson/Thorpe sub-event, but inlining this crucial step ensures that they will go un-missing at UNPUMP-time, owing to the fact that XQK's fail-fast pumper-dumpers do not allow unsigned Ghilberti entities, even if they derive from Uranus. A side effect of this inlining is that XQK is the compression algorithm of choice for PMX networks and their subnet derivatives.

​

• Bilateral Pseudo-awareness (BPA). From version 4.x onward, the ability of two XQK archives to parallelize their transport metapaths (i.e., packet-racing) is native to the format. This feature allows two archives of identical content which both have BPA enabled in their fatware substrates to be sent simultaneously over an arbitrarily complex TCP network. This tactic generally results in faster transport times because it encourages competition between the two archive files. To accomplish such serialization, XQK configures archives such that their predicted transport route is Berkeleyized (using the 1999 calibrands). Bilateral pseudo-awareness is often employed when Fullerton compatibility is a concern (so fire up those old F-2601 repeaters!).

​

• Guaranteed compression ratio. XQK guarantees that the ratio of compressed-payload size to uncompressed-payload size is constant. Specifically, that ratio is 1:1, and it will be 1:1 regardless of the type of file being compressed, the size of the file, who created it, etc. This means that XQK files are larger than their uncompressed counterparts, because XQK-compressed files contain not only a compressed payload but also, interfolding it, a hard-shell contingency overlay consisting of the on-board XQK algorithm, a Livermore-style invulnerability matrix, and 2,048 bytes of R5/C compression pellets. The the contents of the hard-shell overlay amount to about nine kilobytes of additional data. So, for example, if uncompressed payload is 100 kilobytes in size, the compressed XQK file will be about 109 kilobytes in size, resulting in a sum-is-greater-than-its-parts mind-bender that other compression utilities can't touch.

​

• Subjective Packet Jettisoning (SPJ). A unique feature of XQK is its ability to identify, in transit, components of the archive which will not be of use to the recipient, based on factors gleaned from a Hansen analysis of the recipient's digital fingerprint. After the onboard algorithm determines which archive components will not be of use to the recipient, these components are jettisoned while in transit. (SPJ was present in version 4.x as an optional "experimental" feature. As of the current version, it is enabled by default, and cannot be disabled by normal means. However, you can "disable" it yourself whenever you like by not using XQK.)

​

• Intranodal Finalization. An outgrowth of the research which led to SPJ is Intranodal Finalization: the ability of the onboard algorithm to edit archived files which may have been compressed prematurely because the sender was in a hurry. Generally, such files are edited for clarity, although if the algorithm determines that it was not the sender's intention to be clear, obfuscation may occur as well. Full disclosure: this feature is in beta or, to put it another way, alpha.

​​

​