Loading ...
Sorry, an error occurred while loading the content.

Re: [decentralization] Streamer

Expand Messages
  • Lucas Gonze
    ... For music I think that Gordon s take is more clueful: ==================== (from http://www.oreillynet.com/cs/weblog/view/wlg/1626) We need net radio
    Message 1 of 17 , Jun 30, 2002
    • 0 Attachment
      > "Streamer is an internet radio program that allows anyone to broadcast
      > streaming mp3 music, to an unlimited number of listeners, from an
      > internet connection as humble as a 56k modem, and with the broadcasting
      > pc being fairly untraceable. It works by relaying the mp3 data stream
      > from one listener to the next, forming a branching tree with the
      > broadcasting pc at the base. "

      For music I think that Gordon's take is more clueful:
      ====================
      (from http://www.oreillynet.com/cs/weblog/view/wlg/1626)

      We need net "radio" that pulls its content, as-needed, from a P2P sharing
      space.

      The "broadcaster" would really just provide an ever-refreshing playlist, a
      window on the last X minutes of contiguous content, with reliable (hash)
      identifiers naming each segment of media to play. "Tuners" would fetch the
      playlist, and scour any and all available sources for matching content
      fragments, grabbing them seconds to minutes before they are needed,
      playing them for the local listener in order and without gaps, resharing
      them for as long as possible, discarding them when necessary.
      ====================

      It's good that this has high resistance to subpoena attack, given that
      internet radio is now all but illegal. But also getting rid of the
      broadcast metaphor is a really good thing.

      A listener picks up a playlist. They dump into into a filesharing app.
      The app slowly assembles the songs as they become available. ...given a
      time delay to get your first playlist loaded, you should always have a few
      radio shows cached. It's like tivo except that there's no broadcasting
      ever.

      That's a little different from Gordon's thing, I guess -- I'm assuming a
      timeframe of hours to days instead of seconds to minutes.

      A cool thing is that listeners would be able to modify and republish
      playlists, which would lead to an evolutionary algorithm for playlist
      generation as better modifications prospered.

      - Lucas
    • brandon@blanu.net
      ... The general idea here is cool. There s a stream splitter implementation in the Tristero CVS at the moment, just missing the tree creation logic. I found
      Message 2 of 17 , Jul 2, 2002
      • 0 Attachment
        > Any thoughts on this one?
        > http://www.chaotica.u-net.com/page/streamer.htm

        The general idea here is cool. There's a stream splitter implementation
        in the Tristero CVS at the moment, just missing the tree creation logic.

        I found this particular project to be too immature to be useful (also
        OpenDj, mentioned that day on slashdot as an alternative). I also don't
        think that this approach is the best way to go except for streams which
        need to be both live and multicast, which is a narrow market. Even with
        semi-live streams you can just lag the stream by 5 minutes, break it
        into series of 1-minute files, and then swarm-download them in
        sucession, stitching them back into a stream on the client side.
      • brandon@blanu.net
        ... This is something that Gordon and I discussed in the historic Bitzi-Tristero lunch, and is in fact my current Tristero application project. Tristero will
        Message 3 of 17 , Jul 2, 2002
        • 0 Attachment
          > For music I think that Gordon's take is more clueful:
          >
          > We need net "radio" that pulls its content, as-needed, from a P2P sharing
          > space.

          This is something that Gordon and I discussed in the historic
          Bitzi-Tristero lunch, and is in fact my current Tristero application
          project. Tristero will let you download the files in the playlist from
          whatever hash-based file retrieval services are available and then look
          up metadata via any available hash-based metadata retrieval services
          (i.e. Bitzi and MusicBrainz).

          I think it's unfortunate that AudioGalaxy shut down as they were poised
          to launch this exact application with a widely deployed userbase and a
          whole lot of content.
        • brandon@blanu.net
          ... This is a really interesting project. It s a general mechanism for doing IP multicast over unicast links. This package should be used by anybody attempting
          Message 4 of 17 , Jul 2, 2002
          • 0 Attachment
            > Good, somebody reinvented YOID and put a UI on it.
            >
            > http://www.isi.edu/div7/yoid/

            This is a really interesting project. It's a general mechanism for doing
            IP multicast over unicast links. This package should be used by anybody
            attempting to write one of these popular multicasting over a tree
            structure applications. They even have a software release which wraps
            the standard UNIX audio and videoconferencing tools rat and vat so that
            they work over the YOID network. Without any change to the rat/vat
            source! Way cool!
          • Damien Stolarz
            ... We ve learned that there need to be many different implementations of all these technologies. The more the merrier, and the chance one will survive,
            Message 5 of 17 , Jul 2, 2002
            • 0 Attachment
              > From: Wes Felter <wesley@...>
              > Good, somebody reinvented YOID and put a UI on it.

              We've learned that there need to be many different implementations of all
              these technologies. The more the merrier, and the chance one will survive,
              software darwinism, etc.


              > We need net "radio" that pulls its content, as-needed, from a P2P sharing
              > space.
              This is also an idea that Brewster Kahle (http://www.archive.org/) is
              immensely interested in. SMIL actually has all the syntax for such a thing;
              (doing client-side on-the-fly mixing of server-side-stored movies); however,
              real and quicktime have only implemented rudimentary support for SMIL enough
              to insert interstitial ads.

              Brewster has a ton of bandwidth and storage and would welcome any volunteers
              who want to put together such client software. The same system would work
              for centralized and p2p media sources- it's mostly client side fetch and
              scheduling, reassembly. A fairly solved problem.

              > But also getting rid of the
              > broadcast metaphor is a really good thing.

              Conference calls are broadcast.
              Real-time events are broadcast.
              Weblogs are broadcast.

              I really like the broadcast metaphor, even tangible broadcast.
              Don't get rid of it.
              Shared temporal interaction doesn't have to be bad.


              --
              Damien Stolarz
              dstolarz@...
            • Lucas Gonze
              ... How temporal? How short a span? TV news can wait until 7 or 11, the papers can wait 24 hours, NPR rebroadcasts recorded segments in short loops. Most
              Message 6 of 17 , Jul 3, 2002
              • 0 Attachment
                On Tue, 2 Jul 2002, Damien Stolarz wrote:
                > I really like the broadcast metaphor, even tangible broadcast.
                > Don't get rid of it.
                > Shared temporal interaction doesn't have to be bad.

                How temporal? How short a span? TV news can wait until 7 or 11, the
                papers can wait 24 hours, NPR rebroadcasts recorded segments in short
                loops. Most stuff has no need for instantaneous broadcast. If a news
                item would be worthy of interrupting your regularly scheduled programming,
                sure. Otherwise, this is a horseless carriage.
              • burton@openprivacy.org
                ... Hash: SHA1 ... I have recently given a lot of thought about this. MP3 streaming via Magnet URI links in RSS would be very compelling. I just
                Message 7 of 17 , Jul 5, 2002
                • 0 Attachment
                  -----BEGIN PGP SIGNED MESSAGE-----
                  Hash: SHA1

                  Damien Stolarz <lists@...> writes:

                  > > From: Wes Felter <wesley@...>
                  > > Good, somebody reinvented YOID and put a UI on it.
                  >
                  > We've learned that there need to be many different implementations of all
                  > these technologies. The more the merrier, and the chance one will survive,
                  > software darwinism, etc.
                  >
                  >
                  > > We need net "radio" that pulls its content, as-needed, from a P2P sharing
                  > > space. > This is also an idea that Brewster Kahle (http://www.archive.org/)
                  > > is > immensely interested in. SMIL actually has all the syntax for such a
                  > > thing; > (doing client-side on-the-fly mixing of server-side-stored movies);
                  > > however, > real and quicktime have only implemented rudimentary support for
                  > > SMIL enough > to insert interstitial ads.
                  >
                  > Brewster has a ton of bandwidth and storage and would welcome any volunteers
                  > who want to put together such client software. The same system would work for
                  > centralized and p2p media sources- it's mostly client side fetch and
                  > scheduling, reassembly. A fairly solved problem.
                  <snip/>

                  I have recently given a lot of thought about this.

                  MP3 streaming via Magnet URI links in RSS would be very compelling.

                  I just blogged about it here:

                  http://www.peerfear.org/rss/permalink/1025898149.shtml

                  This would then allow RSS aggregators (that became smart enough) to also become
                  M3U servers. Users could publish Magnet URIs to MP3 files with their RSS
                  publishers and when pulled locally would bootstrap P2P clients that could handle
                  this. As long as the MP3 isn't needed RIGHT away this would work out very well.

                  Reptile would do a good job at this. We could cache the MP3 files on the server
                  for future delivery (assuming no legal issues or we would be sued out of
                  existance).

                  Kevin

                  - --
                  Kevin A. Burton ( burton@..., burton@..., burton@... )
                  Location - San Francisco, CA, Cell - 415.595.9965
                  Jabber - burtonator@..., Web - http://www.peerfear.org/
                  GPG fingerprint: 4D20 40A0 C734 307E C7B4 DCAA 0303 3AC5 BD9D 7C4D
                  IRC - openprojects.net #infoanarchy | #p2p-hackers | #reptile

                  Any sufficiently advanced Operating System is indistinguishable from Linux.
                  - Jim Dennis
                  -----BEGIN PGP SIGNATURE-----
                  Version: GnuPG v1.0.7 (GNU/Linux)
                  Comment: Get my public key at: http://relativity.yi.org/pgpkey.txt

                  iD8DBQE9Jf9pAwM6xb2dfE0RArceAKDOyTmBJEKXCAxR64l9R71jTMnhjwCdGPwA
                  J0OeIvNTS8QNpE76SUoAzvQ=
                  =wV/i
                  -----END PGP SIGNATURE-----
                • Kevin Prichard
                  this popped up on /., lacks useful detail, but it sure looks interesting- http://www.newscientist.com/news/news.jsp?id=ns99992510 -kevin prichard
                  Message 8 of 17 , Jul 6, 2002
                  • 0 Attachment
                    </lurk>

                    this popped up on /., lacks useful detail, but it sure looks interesting-

                    http://www.newscientist.com/news/news.jsp?id=ns99992510

                    -kevin prichard

                    <lurk>
                  • Justin Chapweske
                    IMO this is what Kazaa has always done. ... -- Justin Chapweske, Onion Networks http://onionnetworks.com/
                    Message 9 of 17 , Jul 7, 2002
                    • 0 Attachment
                      IMO this is what Kazaa has always done.

                      Kevin Prichard wrote:
                      > </lurk>
                      >
                      > this popped up on /., lacks useful detail, but it sure looks interesting-
                      >
                      > http://www.newscientist.com/news/news.jsp?id=ns99992510
                      >
                      > -kevin prichard
                      >
                      > <lurk>
                      >
                      >
                      > To unsubscribe from this group, send an email to:
                      > decentralization-unsubscribe@egroups.com
                      >
                      >
                      >
                      > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
                      >



                      --
                      Justin Chapweske, Onion Networks
                      http://onionnetworks.com/
                    • Johannes Ernst
                      ... I may be off-base here, but isn t that essentially the question is a breadth-first or a depth-first algorithm better at finding things? With Gnutella
                      Message 10 of 17 , Jul 7, 2002
                      • 0 Attachment
                        At 15:36 -0700 2002/07/06, Kevin Prichard wrote:
                        ></lurk>
                        >
                        >this popped up on /., lacks useful detail, but it sure looks interesting-
                        >
                        > http://www.newscientist.com/news/news.jsp?id=ns99992510
                        >
                        >-kevin prichard
                        >
                        ><lurk>

                        I may be off-base here, but isn't that essentially the question "is a
                        breadth-first or a depth-first algorithm better at finding things?"
                        With Gnutella being the breadth-first, and what's described there
                        being a depth-first?

                        I can believe that this random-walk algorithm is somewhat more
                        efficient in terms of total messages sent for one query because the
                        number of "overhang" messages is probably smaller. "Overhang
                        messages" being the ones which are still sent after a result is found
                        somewhere on the network because other peers don't know that a
                        solution has been found.

                        Otherwise, it would be interesting if someone found an effective way
                        of implementing an A* -type algorithm in a p2p system. Anyone ever
                        done that?
                      • Lucas Gonze
                        ... The Lv paper is a refinement on Search in Power-Law Networks by Lada Adamic. [background: the Adamic paper is about a specific way of walking a power law
                        Message 11 of 17 , Jul 7, 2002
                        • 0 Attachment
                          > I may be off-base here, but isn't that essentially the question "is a
                          > breadth-first or a depth-first algorithm better at finding things?"
                          > With Gnutella being the breadth-first, and what's described there
                          > being a depth-first?

                          The Lv paper is a refinement on "Search in Power-Law Networks" by Lada
                          Adamic.

                          [background: the Adamic paper is about a specific way of walking a power
                          law graph, a self-avoiding degree-seeking random walk in a network with
                          indices cached to two hops from the source. This was found to cover a
                          large portion of the graph in a tiny number of hops. my memory is that
                          50% of a 1000-node cluster is searched in less than 20 hops. The trick
                          that makes this work is that the walk always moves to the best connected
                          neighbor, so a query gets sucked into hot spots after just a few
                          preliminary hops, and hot spots perform the same role as hubs in a
                          hub-and-spoke design.]

                          Adamic's strategy is completely depth-first. There's one walker for any
                          search, and the search path is a single line. What Lv does is a hybrid of
                          depth first and breadth first, using a small number of random walkers,
                          each of which goes in a degree-seeking self-avoiding line. To catch
                          overhang messages, each random walker checks back with the query source
                          every few hops.

                          Here's the Lv paper, courtesty of Adriana Iamnitchi:
                          http://groups.yahoo.com/group/decentralization/message/5509

                          > Otherwise, it would be interesting if someone found an effective way
                          > of implementing an A* -type algorithm in a p2p system. Anyone ever
                          > done that?

                          A*, Johannes?

                          - Lucas
                        • Johannes Ernst
                          Thanks for the clarifications. At 19:43 -0400 2002/07/07, Lucas Gonze wrote: ... Goes back to AI in the 70 s as far as I know (but then, I m just an EE
                          Message 12 of 17 , Jul 7, 2002
                          • 0 Attachment
                            Thanks for the clarifications.

                            At 19:43 -0400 2002/07/07, Lucas Gonze wrote:

                            <snip/>

                            > > Otherwise, it would be interesting if someone found an effective way
                            >> of implementing an A* -type algorithm in a p2p system. Anyone ever
                            >> done that?
                            >
                            >A*, Johannes?

                            Goes back to AI in the 70's as far as I know (but then, I'm just an
                            EE so I might not know). I read about it first in Winston's
                            Artificial Intelligence, MIT 1979. (I quoted it in my PhD thesis but
                            don't actually own the book so this is from -- weak -- memory)

                            It's basically a search algorithm that selects the next node based on
                            an estimate of the distance between the current node and where the
                            result may be. As far as I recall, it is proven to be optimal (with
                            respect to the number of nodes traversed) for "good-enough"
                            estimation functions. Depending on what the estimate says, it turns
                            out to be breadth or depth first at the extremes. Surprisingly, "good
                            enough" does not need to be particularly good. I think
                            underestimation of distance was always okay, overestimation was bad,
                            but I would think that one should be able to distribute data over a
                            p2p network in a way that a corresponding "appropriate" estimation
                            function could be constructed?!?
                          • Lucas Gonze
                            ... neat. so you d structure the topology to enable estimation functions. it s a cross between unstructured networks like gnutella and distributed hash
                            Message 13 of 17 , Jul 8, 2002
                            • 0 Attachment
                              Johannes Ernst wrote (about A*):
                              > It's basically a search algorithm that selects the next node based on
                              > an estimate of the distance between the current node and where the
                              > result may be.
                              ...
                              >I would think that one should be able to distribute data over a
                              > p2p network in a way that a corresponding "appropriate" estimation
                              > function could be constructed?!?

                              neat. so you'd structure the topology to enable estimation functions.
                              it's a cross between unstructured networks like gnutella and distributed
                              hash tables.

                              you could explain the 'search in power law networks' algo as:
                              1) because they have more cached indices, big nodes are most likely to
                              contain the listing you want.
                              2) the degree-seeking search path assumes that shortest path is via the
                              biggest nodes.

                              - Lucas
                            • cefn.hoile@bt.com
                              This is something like SWAN s approach. SWAN networks are unstructured, but automatically structure the topology of links to permit the follow next nearest
                              Message 14 of 17 , Jul 12, 2002
                              • 0 Attachment
                                This is something like SWAN's approach. SWAN networks are unstructured, but
                                automatically structure the topology of links to permit the 'follow next
                                nearest' local routing algorithm to work.

                                Cefn

                                -----Original Message-----
                                From: Lucas Gonze [mailto:lgonze@...]
                                Sent: 08 July 2002 15:08
                                To: decentralization@yahoogroups.com
                                Subject: Re: [decentralization] random walk searches

                                ...

                                neat. so you'd structure the topology to enable estimation functions.
                                it's a cross between unstructured networks like gnutella and distributed
                                hash tables.

                                ....

                                - Lucas



                                To unsubscribe from this group, send an email to:
                                decentralization-unsubscribe@egroups.com



                                Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
                              • David Helder
                                Check out Emcast too: http://www.junglemonkey.net/emcast It s a library and tool (like netcat) for multicast. It supports IP Multicast, BTP (my end-host
                                Message 15 of 17 , Aug 12, 2002
                                • 0 Attachment
                                  Check out Emcast too:

                                  http://www.junglemonkey.net/emcast

                                  It's a library and tool (like netcat) for multicast. It supports IP
                                  Multicast, BTP (my end-host multicast protocol), and a few other simple
                                  protocols (IRC, star topology).

                                  David


                                  On Tue, 2 Jul 2002 brandon@... wrote:

                                  > > Good, somebody reinvented YOID and put a UI on it.
                                  > >
                                  > > http://www.isi.edu/div7/yoid/
                                  >
                                  > This is a really interesting project. It's a general mechanism for doing
                                  > IP multicast over unicast links. This package should be used by anybody
                                  > attempting to write one of these popular multicasting over a tree
                                  > structure applications. They even have a software release which wraps
                                  > the standard UNIX audio and videoconferencing tools rat and vat so that
                                  > they work over the YOID network. Without any change to the rat/vat
                                  > source! Way cool!
                                  >
                                  > To unsubscribe from this group, send an email to:
                                  > decentralization-unsubscribe@egroups.com
                                  >
                                  >
                                  >
                                  > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
                                  >
                                  >

                                  --
                                  __ _ __ David Helder - dhelder@...
                                  ___/ /__ __ __(_)__/ / <http://www.eecs.umich.edu/~dhelder>
                                  / _ / _ `/ |/ / / _ / Jungle Monkey: <http://www.junglemonkey.net>
                                  |_,_/|_,_/|___/_/|_,_/ Paper CD Case: <http://www.papercdcase.com>
                                Your message has been successfully submitted and would be delivered to recipients shortly.