[mythtv-users] possible p2p approach for mythtv information?

[Brad Templeton]

On Thu, Jul 06, 2006 at 08:03:08PM +1000, Aaron Harwood wrote:
> It takes only a small fraction of peers to be operating with public  
> IP addresses
> for the system to boot strap. In most cases there are some users who are
> willing to run a "24/7".

Indeed, but unlike many P2P systems where inherently you've got some
fraction of the machines with external IPs, Mythtv tends to run more
on appliance boxes where this is far less likely.

(Now I should talk, in fact I _do_ have my master backend server with
an external IP address myself.  But I am just guessing that is pretty
rare.)

However, my point is that the application here is a collaborative
database.   P2P is the right design when individual peers have information
for individual peers, so of course they should send it directly.  Here
we have some very different constraints:

    o) I want, in some sense, information from anybody with data/input on
       a given show, and likewise, my information on a show is to make it
       out to everybody.
    o) I don't actually want their raw information, I want a distillation of
       it.

This just doesn't fit the P2P design.  I now how P2P designs
work.   I'm on the board of BitTorrent, after all.   This is just one
of those places where trying to do it P2P makes it harder to do,
gains you very little, and costs you lots of bandwidth.

> This can depend on the bandwidth requirements. P2P works well when the
> amount of information that is being communicated is too much for a  
> central server.

Which is not only not the case here, it's completely the opposite.
For example, for cutlists, I don't want everybody's impressions of
where the commercials are.  Rather, I want one server to combine all
those figures into the answer they are converging on.   So 10,000 cutlists
are compressed down to 1, or if you really want to run your own algorithms,
there are ways to compress the 10,000 cutlists losslessly to a tiny fraction
of their size.

Not that cutlists, or show recommendations, are particularly large to
begin with.
> 
> Owners of the central server would often resort to advertisements or  
> charging
> for access in order to maintain the system. While this is a widely  
> accepted business
> model, it can be undesirable from the users' point of view. This  
> particular point has
> much more to debate though.

Except that running the central server for a particular show would be
little higher than the load of being a peer in a true P2P network.

That's because random peers can't be trusted to aggregate data from other
peers for you, the way you can decide to trust a particular server.
I can envision ways to try to make this better with complex PKIs etc. but
this is a lot of complexity for little gain?

Now a good system would allow multiple central servers, even multiple ones
for the same show, and ready switching among them, so no one server
can annoy the people it is supposed to help.   But it a protocol for sharing
cutlists or sharing show ratings, it's hard to see how to insert ads in
a way people would tolerate in the slightest.   (Ie. the only way to do it
would be a fake cutlist that deliberately made you see an ad, or a fake
recommendation that made you watch a show, and people would revolt the first
time you tried this.)