message propagation in a network, p2p approach, part 3

Me and a friend sat together and discussed this torrent stuff. It was lovely to get more input. Hopefully i was not pushing him too much about this topic. :-)

We have discussed mainly:

• How to represent an endless stream

Yeah, how?

Lets say, i install a webcam somewhere. Then there is a station, which captures the video stream from the cam and it writes the data into a file, a bytestream always growing in size.

This station creates metadata about this stream, creates a unique id, and publishes it. Other peers pick it up and leech the data.

But torrent files are considered to be static files. They sum up an existing source. It does not work on a stream, which is supposed to grow in size in the future.

Then we came up with the term of "linked torrents".

We assume, that a station knows for sure about the past and it can make statements about the future.

The station creates a bytestream with the length of, lets say, 100MB, which would fit for webcam data of about 10 minutes. It fills it continuously with the data from the webcam. If the stream is full or a timeout arrives (because the cam did not send any data anymore), then the torrent is ready to be completed. It describes the stream and it can be published.

Additionally the station will already add the ID of the next bytestream as well. It links itself to the next torrent. This identifies the torrent for the future:

• torrent[0] = "torrent describing the whole stream project"
• prev(torrent[0]) = "" | "meta torrent of whatever, universe, company, etc. etc. reflecting a status at the present time"
• prev(torrent[n+1] = torrent[n]
• next(torrent[0]) = torrent[1]
• next(torrent[n]) = torrent[n+1]

Each future torrent might quote the content of the previous torrents as well or just their IDs or just a selection of IDS. In any way, the torrent links itself to at least one previous torrent, if its not the starting torrent.

Since the station is the publisher, it can also make statements about the future, when the next torrent might become available. It could say torrent(0) arrives at a time X, torrent(1) arrives at a time Y. Without warranty, of course. This could help indexing the torrents. And for clients its helpful.

So, a client in the future, who watches a live stream of the present time, might be able to rewind 10, 100 years ago. As long as there are peers available, who have stored the data. (Archiver peers, why not, like a national library)