It somehow and "somewhen"struck me to use the Internet as a storage medium when i first heard of the hop-by-hop translation of an Internet packet. I suppose that I supposed that I would just send my file into the Internet and make it hop around continously between the routers until such time when I needed that data, at which time I would just sorta "call'em home". It seemed simple and great. Later when I learnt of the TTl (Time To Live) fields in IP packets, my dreamed up Internet Memory of sorts seemed more plausible. I thought that if I could somehow fool the routers to accept a large TTL value, I could make the packet hop around for eternity (well, it didn't strike me why the Internet hasn't ground to a halt with too many packets doing infinite rounds). And when I wanted my packet, I would *somehow* make one of the routers in the loop to forward the packet to me on the next hop through it.
Reminiscing this old thought, I now feel that the above idea can work by using your own Routers in the loop, IP Source-Routing and a lot of hackish coding. No need for a TTL hack. But I don't exactly know if it would work yet. For example, the protocols may not allow a looped source routing, or the router may not respect the source routing (the RFC allows for this behaviour). U can avoid loops in routing by maintiaining two routers, with one router routing data to your other one, hence showing no loops in the routing. I haven't tried any of this, ofcourse. I don't have two routers for a start. And then there's the fact that I am not a Hacker. But I would be happy to know if someone had already done it or is planning to do it.
Moving on to the reasons behind how this "Memory" might work, only one word for you: DRAM. That's right, Dynamic RAM's working principle is the closest that U can analogize here. As u may know, in a DRAM, a memory location forgets what data it holds unless an internal circuitry "reminds" it of the data periodically. Forget to refresh it, and u've lost the data stored in there. But the important thing to notice here is that u don't need a second memory stick of the same capacity from which to refresh the DRAM. Also, the forgetfulness of the DRAM chip does not make us shirk it as a Main Memory in our computers. The reason that we even consider it is that it can remember what it is told for some quantum of time.
Comparing the memory to the Internet, I hope that you can see how it was easy to arrive at my conclusion that data can be stored by looping it around a known route. The Internet delay/latency, though being a dark gray pestilent cloud, has the silver lining of allowing the data to be temporarilly "lost" and then recovered back, thus replicating a temporary storage.
I am no great shakes with numbers, but if u take into consideration the following:
>input and output queue lengths and sizes of each box along the route,
>processing delay of each box,
> the Path-Length,
>Path-delay,
>the MTU of the path,
and coupled it with your own bandwidth, U can pretty much guess exactly how much you can store in this "Roaming Memory" (heh, had to mention it *somewhere*) of yours.
You could also be juggling many data packets at the same time, each packet travelling down it's own source-routed path. The number of such concurrent packets that your connection can handle can be easily calculated by knowing the data packet sizes, the amount of overhead associated with TCP/IP, ATM (if any) and anything else. Ofcourse, to have a larger memory, you can send different packets through each memory route, or for more robustness against packet loss(!) along a path, u can have a duplicate memory path for each packet.
Now to think of how actually you would call home a packet. First off, u can send in some ID code in each packet so that we can ask our router to retract in the right packet from the loop. Here comes the hackish coded application that I was talking about. This app will have to coordinate the packet routes, routing policy of the routers, setting a new packet of data in the loopy-motion, asking a router to retract a packet of the loop, putting different IDs on the packets, maintaining an ID-to-what it contains table and everything else I missed.
If u are perplexed as to why I should resort to such a twisted way of storage and why I didn't think of GDrive-like tactic of utilizing the email space, then u do have a point. But, since email follows the store-and-forward method of sending messages, you have a large delay. What my idea provides is a very low latency and high speed but a very small size memory. More like a cache memory in ur processor/mother board. Using GDrive-like idea will give u a very high latency, but large memory. Kinda like the main memory/hard disk in ur computer.
