In the pre-smtp days, email links were over UUCP, which was often relayed via dial up lines which connected intermittently, on a schedule (e.g. every hour).
Add in the situation of disk quotas for university students, but not email quotas, and you get the means, motive and opportunity for people to use the email spools of a mail servers around the world as an annex to their home directory...
Since the statute of limitations has expired I will admit to creating data archival systems using uucp as well as smtp. Back in the 80s before the morris worm and spam, when the internet was just for us geeks, you could usually connect to anyone's mail server on port 25 and hand it mail to be delivered just about anywhere. Sendmail was more concerned with connecting up all of the various networks than it was about authenticating a destination, so you could connect to just about anyone's mail server and ask it to deliver mail back to your server; of course your server would be conveniently offline for a period of time or drop the connection after checking the rcpt (chunk id) in the envelope until you either wanted the data back or needed to accept it so that it did not bounce. I probably have opq ("other people's queue") on a nine-track tape in the basement but have no way of loading it up again; anyone know what the odds are that a well-cared for tape reel circa 1986 (bad tar format) is actually worth sending somewhere to get read?
Similarly, in the early AOL days, there were several "warez" distribution lists going around which had the pirated software directly attached to the emails (not links to external websites). As long as the emails stayed in AOL, you could forward them instantly (there must have been some deduplication on the back end making the attachments basically a link to the same files).
Technically, the data is not stored in the network, but in the buffer memory of the routers (and switches) in the path of the packets. So what this is really doing is externalizing the cost of storage to the network providers.
There is a problem called “Buffer bloat”¹ which is that many manufacturers of networking equipment provide too much buffer memory, which leads to TCP latency and timeouts, since TCP was not designed with these large buffers in mind. Using Pingfs will take up buffer space in networking equipment. This could either be a good thing, since it decreases the available buffer space, or it might be a bad thing since it might make networking providers increase their buffers.
A teacher told me in the 70s they used satellite communication as memory buffers, sending data over the air with getting it back a bit later as only goal. IIUC, the earliest form of memory device were doing the same using pressure waves in mercury.
I dunno, this is actually very reminiscent to me of how neurons (putatively) store information in their firing rates--at least in the short-term--before consolidating state into their synaptic weights.
This is crazy cool. Nevertheless, if everyone used it, we would saturate whatever network we are using and I am curious what it would do to traffic costs since you are basically bouncing around a whole bunch of data back and forth. Sounds expensive.
Just like with iodine (dns tunnel) this was one thing me and my friends talked about that would be cool.
I actually started to implement this in haskell in 2011, and gave up after I had basic writes to files working. I can get dig out that code if anyone is interested.
The c version of the project hasnt gotten very far yet as you can see, I might pick it up again though.
You don't need ICMP for that, or even an active space probe. Just encode your data in laser pulses and bounce it off one of the retroreflectors we've put out there. There are at least three on the moon, or the LAGEOS satellites (https://en.wikipedia.org/wiki/LAGEOS) would work.
Hmm - quick research shows that laser communications have been demonstrated at up to around 1Gb/s; given the roundtrip time to a retroreflector on the moon, you could have around a 300MB buffer in flight at a time. Average latency to read or change a particular byte would be about 1.2 seconds, so not ideal for high performance applications. Also, wouldn't work when the moon was below the horizon. Plus installing additional retroreflectors on the moon to increase capacity would be quite expensive.
You don't need more retroreflectors, just ground lasers far enough apart (and someone with more physics than me to make an argument about the waves not interfering at the reflector)
Could do some crazy docker things with this. Imagine bouncing around your entire P2P net on a .bit domain. Makes popcorn time look like a bunch of amateurs.
Hi bandwidth is desirable too because it's delay * bandwidth. From my location I think the optimal place might be hawaii, the place with the highest delay bandwidth product I mean. It might be optimal for other reasons too.
ping packets (ICMP) can have any data you want as a payload (1,500 bytes or so). This is a joke filesystem that lets you store data by putting it in ping packets and sending them to other systems. To read the data, you just wait for the ping response to come back. Then, you send it again immediately so that you don't have to store it locally.
The amount of data you can store is a factor of the amount of bandwidth you have and the amount of latency available, where the more latency is better. Hypothetically, on a 10 gigabit connection with a 1 second ping time, you'd be able to store 1,250 megabytes. Of course that doesn't factor in packet loss, and finding something that's one second away that also can saturate a 10 gigabit connection is unlikely.
ICMP Echo packets or Ping packets send data to a (given) server which then replies with the exact packet (data) in return. In essence this program bounces your data back and fourth between a (given) server and your computer instead of storing it on a drive or on someone else's drive it. So your data is living on the internet, in the internet's delay between you and the remote server. This can be unsafe data storage if the link between you and the remote server ever dropped.
Delay lines built on this principle were used in some old analog color TVs, for purposes of color correction: color info for a line was compared to the previous line, and differences were smoothed out. This resulted in less color resolution on the vertical, but also greatly reduced color noise and error.
The signal in the line was ultrasonic sound waves.
Delay filters are built intentionally by RF engineers for pre-distortion and probably other purposes. I think the limit for such simple designs is ~100 ns.
A long time ago as a joke a few of us sketched out "netfs" that would use network switch forward buffers as a filesystem in a similar manner (constant resending), but never actually tried to make it. This is really neat.
You also specified not just the destination, but also the route for the email to take, via a 'bang path': https://en.wikipedia.org/wiki/UUCP#Bang_path
Add in the situation of disk quotas for university students, but not email quotas, and you get the means, motive and opportunity for people to use the email spools of a mail servers around the world as an annex to their home directory...