05-06-2016, 02:36 AM

I have this idea for saving bandwidth using a compression(?) idea I've been thinking about, but I really need to hammer out details before I continue. The idea is to use a timing mechanism to cut down the amount of bytes sent.

We start with a 3d box fill with cubes. The exact dimensions can be adjusted, but in this case the box is 65536x16x8. Each cube is a byte of data. The values inside the cube are determined by a pseudo random number generator, with a shared seed. This box will (or should in theory) be identical on both ends. Start with the number 0 at the exact beginning of the minute, and incrementing 1 for each millisecond after the beginning of that minute until you reach 65536, filling data along the way. This interval can be represented as a 16 bit number, 2 bytes.

So if the time is 12:34PM, 56 seconds, 789 milliseconds:

0 means 12:34PM, 56 seconds, 0 milliseconds

55 means 12:34PM, 56 seconds, 55 milliseconds

900 means 12:34PM, 55 seconds, 900 milliseconds

Using another 16 bits, 2 bytes, for selecting rows of 8 byte data, makes a total of 4 bytes of bandwidth used for 8 bytes (most likely scenario) to 128 bytes of the file.

In theory, if you have really bad luck, you could wait days, weeks, months, years before the file finishes downloading. I know this, but without tests, I don't know what the most likely scenario is.

Are there any (other) flaws with the design? I'd like to find out now rather than after i start working on it.

TL;DR download anything over the internet using 1 bit of bandwidth. Just start at 0 and count up. See you next millennium

We start with a 3d box fill with cubes. The exact dimensions can be adjusted, but in this case the box is 65536x16x8. Each cube is a byte of data. The values inside the cube are determined by a pseudo random number generator, with a shared seed. This box will (or should in theory) be identical on both ends. Start with the number 0 at the exact beginning of the minute, and incrementing 1 for each millisecond after the beginning of that minute until you reach 65536, filling data along the way. This interval can be represented as a 16 bit number, 2 bytes.

So if the time is 12:34PM, 56 seconds, 789 milliseconds:

0 means 12:34PM, 56 seconds, 0 milliseconds

55 means 12:34PM, 56 seconds, 55 milliseconds

900 means 12:34PM, 55 seconds, 900 milliseconds

Using another 16 bits, 2 bytes, for selecting rows of 8 byte data, makes a total of 4 bytes of bandwidth used for 8 bytes (most likely scenario) to 128 bytes of the file.

In theory, if you have really bad luck, you could wait days, weeks, months, years before the file finishes downloading. I know this, but without tests, I don't know what the most likely scenario is.

Are there any (other) flaws with the design? I'd like to find out now rather than after i start working on it.

TL;DR download anything over the internet using 1 bit of bandwidth. Just start at 0 and count up. See you next millennium