84 lines
5.0 KiB
Plaintext
84 lines
5.0 KiB
Plaintext
NEW VERSION OF FOREM BBS SOFTWARE
|
|
----------------------------------
|
|
A new release of FoReM ST arrived yesterday. Among the features is
|
|
yet another new file transfer protocol, 'ZZZMODEM.' This new protocol
|
|
transfes data in blocks of 16 Megabytes, giving it the largest block size
|
|
of any file transfer protocol in the Known Universe. The checksum for each
|
|
block in a ZZZMODEM transfer is sent via XMODEM, for greater accuracy.
|
|
"This new protocol will allow us to transfer data at rates up to one one-
|
|
hundredth of one percent FASTER than by any previous method," explained
|
|
Phil "Compu" Dweeb, a FoReM aficionado, pausing occasionally to wipe
|
|
the drool from his chin.
|
|
|
|
Industry insiders were quick to point out that using ZZZMODEM, it
|
|
takes roughly 2 hours and 25 minutes to transfer a 20K file at 19,200 baud.
|
|
Mr. Dweeb said that this problem has been dealt with. "Each block is padded
|
|
with nulls, which take no time to send," he explained.
|
|
|
|
The new version of FoReM ST also has the new "Recursive ARCing"
|
|
feature. As Mr. Dweeb explains: "All download files are recursively ARCed
|
|
by FoReM before being put online. Our experience has shown that when you
|
|
ARC a file, it gets smaller. Therefore, the approach we have taken is to
|
|
repeatedly ARC the file until it reaches a size of roughly 10K. At that
|
|
point, it's hardly worth the trouble, wouldn't you say?"
|
|
|
|
Reportedly in the works for a future release is the patented "One
|
|
Length Encoding" process. Early reports suggest that this procedure can
|
|
reduce the length of a file to just 1 bit. Mr. Dweeb takes up the story:
|
|
"One day we were sitting around doing some hacken and phreaken, and one of
|
|
us started thinking. All binary data is encoded into bits, which are
|
|
represented by ones and zeros. This is because a wire can either carry a
|
|
current or not, and wires can therefore be set up in a a series that can
|
|
represent strings of ones and zeros. "Notice, however, that the real
|
|
information is carried in the ones, since the others carry no current. I
|
|
mean, what good does a wire do when it isn't carrying any current? So by
|
|
dropping all the zeros, you can easily cut file sizes in half. So we
|
|
decided that a cool way to speed up data transfer would be to only send the
|
|
one bits. The results were phenomenal -- an average speed increase of 50%!!
|
|
"After we finished the initial implementation, we kept finding ways to
|
|
make the thing faster, and more efficient. But then we realised that we
|
|
hadn't gone all the way. If you think about it, after you drop all the
|
|
zeros, you're left with a string of ones. Simply count all the ones, and
|
|
you're left with another binary string. Say you end up with 7541 ones. In
|
|
binary, that's 1110101110101. So immediately we've reduced the number of
|
|
bits from 7541 to 13. But by simply repeating the process, we can reduce it
|
|
further. 1110101110101 becomes 111111111, or 9, which is 1001, which be-
|
|
comes 2, which is 10, or 1. Once we reach a string length of 1, we have
|
|
reached maximum file com-pression. We now have the capability to encode
|
|
virtually unlimited amounts of information into a single digit! Long-
|
|
distance bills will never be the same! "Now, that's not to say that there
|
|
aren't a few problems. The biggest one we have encountered is that for some
|
|
reason, there seems to be a certain amount of data loss during the re-
|
|
conversion process. It seems that sometimes the file cannot be expanded
|
|
into its original form. So, the solution we came up with was to have an
|
|
encryption key associated with each file. When a One Length Encoded file is
|
|
received and is undergoing decompression, the unique encryption key must be
|
|
supplied. That way, we end up with a 100% success rate in our conversions!
|
|
|
|
"A problem which we are having difficulty resolving lies in the fact
|
|
that to ensure a 100% success rate, the encryption key must be exactly as
|
|
long as the original file. We are confident, however, that the use of our
|
|
Recursive ARCing procedure will help to solve this problem..."
|
|
|
|
|
|
X-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-X
|
|
|
|
Another file downloaded from: NIRVANAnet(tm)
|
|
|
|
& the Temple of the Screaming Electron Jeff Hunter 510-935-5845
|
|
Rat Head Ratsnatcher 510-524-3649
|
|
Burn This Flag Zardoz 408-363-9766
|
|
realitycheck Poindexter Fortran 415-567-7043
|
|
Lies Unlimited Mick Freen 415-583-4102
|
|
|
|
Specializing in conversations, obscure information, high explosives,
|
|
arcane knowledge, political extremism, diversive sexuality,
|
|
insane speculation, and wild rumours. ALL-TEXT BBS SYSTEMS.
|
|
|
|
Full access for first-time callers. We don't want to know who you are,
|
|
where you live, or what your phone number is. We are not Big Brother.
|
|
|
|
"Raw Data for Raw Nerves"
|
|
|
|
X-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-X
|