I've been playing with implementing GZ/BZ2 compression in clrghouz,
which I've been testing with binkd.
I've noticed that size value in M_FILE, is the size (of the file)
before compression.
- M_FIL list.txt 16384 1688519850 -1 BZ2
ie: In this run, list.txt was full of zeros, which compresseses to 46 bytes.
- Compressed 16384 bytes to 46 for list.txt, ratio 0.3%
However, if list.txt was full of random binary data, the chance of it growing is actually high (and it did most times I tested).
- Compressed 16384 bytes to 16867 for list.txt, ratio 102.9%
I was wondering how MBSE handles it? Is the size element of M_FILE the size of the file, or the transfer (I assume the former, which is what
the spec implies).
The problem I'm trying to solve, is that there is no "end of file"
marker being sent by the sender, and since compression is being used,
I dont know how much data to receive before doing the uncompress.
And if the file grows, I dont know how much bigger it will grow. (And
the sender actually ends up waiting for the M_GOT.)
I've worked around it, but curios how MBSE handles it.
I was wondering how MBSE handles it? Is the size element of M_FILE the size of the file, or the transfer (I assume the former, which is what the spec implies).
The problem I'm trying to solve, is that there is no "end of file" marker being sent by the sender, and since compression is being used,
I dont know how much data to receive before doing the uncompress.
You're welcome to have a look at the code; it's available from https://sourceforge.net/projects/mbsebbs/ ...
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 339 |
Nodes: | 16 (2 / 14) |
Uptime: | 03:23:30 |
Calls: | 7,467 |
Calls today: | 3 |
Files: | 12,691 |
Messages: | 5,628,147 |