FAQs
​
Q: Can I compress XQK archives using other compression schemes such as Zip or GZip?
A: Yes, but you will miss out on most of the good stuff that XQK provides. The onboard algorithm employs features such as Bilateral Pseudo-awareness, SPJ, and Intranodal Finalization when it determines that the archive is in transport across a network. Since the algorithm determines this by examining the archive's Koroviev velocity with respect to the local frame (if it is not near-zero, the file is determined to be in transit), the archive will never be in transit as far as XQK is concerned since relative to the (for example) GZip archive containing it, it is stationary. However, if you are looking for a compression algorithm whose use results in smaller files after compression, XQK may not be what you're looking for. Frankly.
​
Q: How does Subjective Packet Jettisoning determine which parts of the archive will not be of interest to the recipient (and which packets should thus be shed in transit)?
A: So, like if you compressed a PowerPoint presentation that had a lot of dumb transitions in it. XQK would remove the dumb transitions if the recipient was likely to think they were dumb.
​
Q: How long has XQK been around?
A: How long have you been around? Nice shirt.
​
Q: Why would I want to use a compression algorithm which makes files larger, not smaller?
A: One of the great things about XQK is that the more files you compress (and the larger those files are), the less it will matter whether they get smaller or not when compressed. Also, concerns about raw file size ignore c27y-related benefits, which generally make archives feel smaller. Also, define "size," right? Finally, of course, XQK's compression ratio is a fixed 1:1. Try finding another compression utility that offers a guaranteed compression ratio.
​
Q: Right, but so then why would I use an archiving tool like XQK at all, if I don't mind large files?
A: Larger than your mom's face? Next.
​
Q: Why are the installer downloads so large?
A: Because they contain a Java runtime. If you already have Java installed on your machine (JRE 1.8+), you can just run XQK's core Jar file (for command-line use), or download the Gzip archive, which contains scripts to run both the command-line tool and the GUI. You won't even need PM/R-22a capability (although if you don't have it, Kellner sheathing will become less of a nice-to-have and more of a not-nice-to-not-have).
​
Q: "Near-lossless?"
A: In a good way. XQK is lossy only to the extent that SPJ jettisons packets which are probably just taking up space. You'll see.
​
Q: BPA sounds great, but how do in-transit archives actually propel themselves while packet-racing?
A: Packet-racing is not a new concept; encouraging two (or more) files to "race" across a TCP network (or, more specifically, encouraging interlocked TCP packets which share the same transport metapath to race from one point to another) has been common practice for some time. As to how they actually propel themselves: TCP packets don't strictly require "propulsion"; a packet-switched network such as the internet moves "passive" (non-self-propelled) packets from one node to another much as one might throw a baseball at someone's house. Most packet traffic on the Internet is "passive." But datagrams involved in packet-racing are almost always self-propelled. For obvious reasons, tiny outboard motors are used in most cases. Mercury SeaPro 115s and 150s are quite common, as are Evinrude E-TEC 115s, usually equipped with Martindale gen-5 skimmers (especially since this article made the rounds). Larger motors provide less maneuverability and generally unneeded kick, while smaller ones generally lack the power to be of use - with the exception of SeaPro 90s when supplemented by being on fire and exploding, providing what is often an impressive "push" across the network.
​
Q: Is there a Java API?
A: Asked and answered but yes. API docs are here. You need xqk.jar and JDK 1.8+.
​
Q: When the OBA dumps packets, either during an SPJ pass or as part of Intranodal Finalization, where do those packets go?
A: Good question; different answers for the former and the latter. SPJ's purpose is to shrink payload size in transit. As such, packets are (or, may be, depending on the recipient's Hansenized protoprofile) literally jettisoned: thrown overboard into the wine-red, packet-switched sea which is the modern internet. Thus, these jettisoned packets, usually after a long trip through the network-wide maze of RFC-10292 endotunnels and Packetmaster etherizers (mostly 252's and 254a's), end up where almost all orphaned packets and other TCP artifacts end up: in the Brooks PHF complex in San Antonio, Texas. (Some packets originating in Asia and "Oceania" end up in a similar military facility near Melbourne, Australia, but these are periodically transferred to the Brooks facility when the TranX-22 intrashaft has excess capacity.)
​
Intranodal Finalization is a different animal. While it grew out of research that led to SPJ, its purpose is not to reduce payload size. While IF may in fact do that, it may just as well increase payload size. When an IF endothread performs an operation which reduces the number of packets in some R-node or similar construct, it simply demobilizes these packets and transfers them to an OBTSA where the 2,048 onboard R5/C compression pellets can work their magic. When the parent archive reaches its destination and its Koroviev velocity is again close to zero, the plasmatized former packets are typically "donated" to the host machine on a no-harm-no-foul basis, which (depending on operating system and hardware) typically "feeds" them to the motherboard, or if all Fanelli registers are full, into the local power grid.
​
​