If cloud storage is virtual disk space spanning a “cloud” of physical servers across the network, PingFS’s data storage is in the lightening that passes through that cloud. PingFS has storage in no static location – its data is always in transition somewhere else. As a result, little physical drive space is needed – it is traded off for a clogged network.
How does this work? Through ping, the simple utility used to test if a machine is up and accessible to us. We ping an IP address (send an ICMP echo request), and it sends back a response. However, you can also attach a snippet of data (a payload), which is sent back verbatim by the receiver. This is used, for instance, to track when the request went out, in order to calculate the round trip.
PingFS breaks files apart and pings parts of them back and forth across the Internet. It is a kind of juggling, where no one machine holds the data for more than a moment; when the message is received, it is immediately tossed back into the ether and cleared from local storage. As Kelson, its original designer puts it, “PingFS is like holding up the clouds by swatting the rain back up.”
“We had recently discussed covert channels (ie, surreptitiously communicating with ICMP packets) and disk redundancy (inspired by https://www.backblaze.com/blog/petabytes-on-a-budget-how-to-build-cheap-cloud-storage/), which sort of merged into a terrible idea.”
While PingFS is written in Python, another implementation was written in Haskell by Erik Ekman. Erik was unaware of Kelson’s implementation, but both came up with the same name (“I guess they also think it has a better ring to it than IcmpFs :)” says Erik). His project grew from an experiment building a DNS tunnel through ICMP, as a clever ploy to avoid fees while in school. He is currently building a version in C, on github here.
RELATED: Another way to offset your data storage – save it in url shorteners
UPDATE: added info on Erik’s version