Subj : MBSE compression transfers
To   : deon
From : Andrew Leary
Date : Wed Jul 05 2023 10:36 am

Hello deon!

05 Jul 23 13:29, you wrote to me:

 de> I've been playing with implementing GZ/BZ2 compression in clrghouz,
 de> which I've been testing with binkd.

 de> I've noticed that size value in M_FILE, is the size (of the file)
 de> before compression.

Correct.

 de> - M_FIL list.txt 16384 1688519850 -1 BZ2

 de> ie: In this run, list.txt was full of zeros, which compresseses to 46
 de> bytes.

 de> - Compressed 16384 bytes to 46 for list.txt, ratio 0.3%

 de> However, if list.txt was full of random binary data, the chance of it
 de> growing is actually high (and it did most times I tested).

 de> - Compressed 16384 bytes to 16867 for list.txt, ratio 102.9%

 de> I was wondering how MBSE handles it? Is the size element of M_FILE the
 de> size of the file, or the transfer (I assume the former, which is what
 de> the spec implies).

It is the size of the original file.  It's been a while since I went near that 
code in binkp.c, but I believe MBSE shuts off compression if it results in the 
data to send growing.

 de> The problem I'm trying to solve, is that there is no "end of file"
 de> marker being sent by the sender, and since compression is being used,
 de> I dont know how much data to receive before doing the uncompress.

 de> And if the file grows, I dont know how much bigger it will grow. (And
 de> the sender actually ends up waiting for the M_GOT.)

 de> I've worked around it, but curios how MBSE handles it.

You're welcome to have a look at the code; it's available from 
https://sourceforge.net/projects/mbsebbs/ ...

Andrew

--- GoldED+/LNX 1.1.5-b20230304
 * Origin: Phoenix BBS * phoenix.bnbbbs.net (21:4/105)

.