On Thu, 11 Aug 2005 22:41:41 GMT, Douglas A. Gwyn wrote:
> Yeah, the idea is an old one.
Didn't sound like such a stunning, novel thing when I heard it either.
> You can't do this in a simple manner, because each hop in any realistic routing protocol
> will decrement the "time to live" counter and discard the packet when it expires.
Either this has been solved or the data is constantly machine gunned out to
keep fresh data available or both. I am only certain of the latter and have
been told of the former.
> Of course, if hosts take an active role in forwarding
> then they can retransmit any received message, in effect resetting the TTL.
I missed that, could you explain please?
> Storage is actually being used, it's just provided (on a temporary basis) by the routing systems.
That's accurate, it is storage since storage has no definition in time
other than there must be some holding of data.
> Here's an idea: why not archive *all* Internet traffic by forwarding
> a copy into such a perpetual routing scheme?
Bandwidth aside, I see no reason, theoretically, that you could not do
this. My experience comes from MB of data but the tests were on TB of data
I am told.
Galicean wrote:
> Bandwidth aside, I see no reason, theoretically, that you could not do
> this. My experience comes from MB of data but the tests were on TB of data
> I am told.
I doubt that volume of data was stored merely by juggling packets. There
must have been some higher-level protocol delivery disk queue involved
(something like the "Class B" storage in the Purczynski / Zalewski paper).
A distributed network of computers under your control (perhaps running
software customized for this purpose) could keep a significant volume of
packets circulating through a network. (providing each participating
computer with random access to the circulating data). But I can't imagine
this reaching the level of a TB of data.
In article <5t3Le.54$sq4.2266233@news.sisna.com>, "Alan" <a__l__a__n@hotmail.com> writes:
> Galicean wrote:
>> Bandwidth aside, I see no reason, theoretically, that you could not do
>> this. My experience comes from MB of data but the tests were on TB of data
>> I am told.
>
> I doubt that volume of data was stored merely by juggling packets. There
> must have been some higher-level protocol delivery disk queue involved
> (something like the "Class B" storage in the Purczynski / Zalewski paper).
>
> A distributed network of computers under your control (perhaps running
> software customized for this purpose) could keep a significant volume of
> packets circulating through a network. (providing each participating
> computer with random access to the circulating data). But I can't imagine
> this reaching the level of a TB of data.
Let's say that you pay $18,000 per month for a 45 megabit circuit with
a 20ms round trip latency.
That's 45 million bits * .020 seconds ~= one million bits ~= 125 kilobytes.
I could store ten times as much data on an ordinary 3.5 inch floppy and
it'd be quite a bit cheaper.
For a terabyte of data you'd need, for instance, a 160 terabit link
with 50 ms latency. Or a collection of links adding up to 160 terabits
would do, as long as the latency was 50ms on all of them.
Call it a million trans-continental OC3s unless I've slipped a digit
somewhere.
> Galicean wrote:
>> Bandwidth aside, I see no reason, theoretically, that you could not do
>> this. My experience comes from MB of data but the tests were on TB of data
>> I am told.
>
> I doubt that volume of data was stored merely by juggling packets. There
> must have been some higher-level protocol delivery disk queue involved
> (something like the "Class B" storage in the Purczynski / Zalewski paper).
Makes sense.
> A distributed network of computers under your control (perhaps running
> software customized for this purpose) could keep a significant volume of
> packets circulating through a network. (providing each participating
> computer with random access to the circulating data). But I can't imagine
> this reaching the level of a TB of data.
Don't know for sure, this was a closed test and only the results was I
privy to. What we are fairly certain of is that it is a piece of a bigger
data storage concept and you may have hit on one of the other aspects of
making the pie.