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

Aaron Harwood aharwood at aerosoul.com.au
Sat Jul 8 02:16:16 UTC 2006


On 07/07/2006, at 4:19 AM, Brad Templeton wrote:

> 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.

It is likely that the MythTV appliance box will want Internet access  
and so half the job
of making it accessible is already done. The other half is port  
forwarding to it,
which is nothing more than a setting.

> (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.)

A little bit more, whatever box/server the user has available on the  
Internet will do, it does
not have to be the same as the appliance box.

> 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.

I wouldn't think it impossible for a P2P design to combine raw  
information as it
flows from peer to peer, so as to reduce redundant information (e.g.  
peers might
arrange themselves effectively into a mesh and thus only communicate  
a small
number of neighbors), or to make use
of an innovative DHT approach. Of course, it would
be more difficult to implement this compared to the centralized  
approach and the
only real benefit I guess is that nobody particularly has to run a  
central server
for everyone else.

> 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.

Did we meet at CodeCon earlier this year?


>> 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.

Yeah. Cut lists would not be very big and they would likely compress  
a lot since
commercials are reasonably regularly spaced and so forth.

However, the information being shared may well grow to include other  
useful
things, e.g. like fixing portions of a show that for some people  
turned out bad
due to reception problems. My neighbor may have received the program  
without
problem, but I've got some noise on the image, so I could correct  
that, potentially
in next to real time... but I guess our discussion is about cutlists  
and not other things.


> 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.

But still, someone has to run it. What happens when they stop running  
it?

>
> 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?

I don't think we need complex PKIs. I was thinking about negative  
reinforcement
as in the original posting that described recommendations.

> 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.

um, kind of peer-to-peer... if each and every user can elect to be a  
server as well.

>   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.)

I'm surprised how some people find out new ways to insert ads. Once  
something
becomes popular then it is always a target for advertisement and the  
incentive is
there for the provider to sell the ad space. E.g., perhaps the  
central site could force
you to "log on" once a week and get a new certificate for your  
cutlist grabber.
When you log on then you are confronted with ads.

--aaron




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mythtv.org/pipermail/mythtv-users/attachments/20060708/947edf3f/attachment.htm 


More information about the mythtv-users mailing list