Inspired by suckerpinch's video on HarderDrives (you should go check it out!),
and the successor to the project, encoder
HARDERDrive is a silly little project I got in mind when I was
thinking up of silly storage methods!
This will soon be a python library, but until then, you'll need
to install it manually.
git clone https://github.com/utkrstht/harderdrive.gitcd harderdrive/pip install -r requirements.txtpython streamer.py-s -m copies (def=1)>
The concept behind HARDERDrive comes from suckerpinch's video.
(go check it out above!))
Basically, we store bits and pieces of information in a ICMP
ping packet, since ICMP pings are echoed/sent-back, we can
keep the ping information in a loop, essentially storing
it in the photons of the fiber optic wires.
Say you're juggling balls (?!), you throw a ball up in the air,
and for a brief period of time, your hands are free since
the ball is in the air, in this period of time you can
throw up another ball, and another, and another, until you
have 5 balls juggling at once (impressive!).
Now, you're obviously not holding all 5 balls at once, you can
hold 2 at a time and throw them in the air, that means
you're saving 3 balls worth of space!
There's obviously a limit to how many balls you can juggle, but
even if you flinged balls in a loop around the earth back
to use, you'll only be ever holding a fraction of the balls
at once.
This means that you're essentially compressing the balls, which
are in this case, the files. Now again, obviously the
file's information can't just go nowhere and reappear out
of nowhere, it has to go SOMEWHERE.
and so We use the fiber optic wires as our storage mediums,
since, as you throw the ball up (send a ping), there is a
brief amount of time where you're not holding the ball, and just as the ball went up, it comes down due to gravity (ICMP ping echo),
and we throw it back up in the air, repeating the cycle.
I've tried really hard, and on the current version, I cannot
store much more than 900kb (1mb~)
In practice, what we do is essentially create a custom ping
packet with scapy, which is 1024 bytes per packet (absolute
maximum size is 1452 bytes afaik), We then manually find an
IP which should be on about the opposite side of the globe,
(e.g. India <-> Chile, vice versa), for highest possible travel time/latency.tency.
We ping the IP (very unethical), with our custom ping packets,
which the IP echoes back to us, during which the ping
packet is travelling through the fiber optic cables essentially stored in the cables.
All the ping packets keep looping between you and the IP, so
whenever we need to recover the file, we can simply cache
the ping packets and recover the file from it.
This is good because we're storing/compressing the file on the
fiber optic cables, now I did say compressing since we
still store SOME amount of data (1-2 ping packets at once)
as we need to "fling" the ping packets back into the loop.
Basically anything below 1mb only takes up like, 4-5kb ram!
- No file more than 1MB or it will drop packets and get corrupted
- Only use IPs close to you if you're streaming small files or it'll bounce too fast and drop some packets
Add CLI support- Add ECC/RS to compensate for dropped packets
- Fix big file size upload issue
- Make it more customizable
- Add a UI because why not
