Slashdot Mirror


P2P Meets Push

meonkeys writes "What if you could securely subscribe to a trusted P2P file broadcaster? Check out konspire! An interesting concept; implemented in C++ and controllable via a cool Web interface ala Mutella."

10 of 264 comments (clear)

  1. What I would like to see.. by JeffSh · · Score: 3, Informative

    a combination of this and torrent.

    this system seems limited by linear pushing 1:1 host:client ratio, and this increases the output logarithmically.

    the problem they are going to run into is that 90% of users on the internet (atleast) have 256 kbps or lower broadband caps, and therefore the network will not efficiently use bandwidth if its 1:1 sends. .torrent makes use of a full upstream of a user to send data. this program does that too, but it does not distribute that users upload-ability accross any more than the one user.

    so anyway, this with .torrent mesh features would be really nice.

  2. unknown files.. by phorm · · Score: 2, Informative

    But from a "trusted" channel. A little better than MS's version of trusted (trust it or it won't work), and you can always unsubscribe from a channel that starts broadcasting content you don't like.

    I was thinking in terms of sharing common music interests (great for indie stuff), but I suppose you could start little clans for those who have certain fetishes in pr0n or gamez as well.

  3. Re:Yes! by moonbender · · Score: 3, Informative

    In fact, this already has been done in exactly that context - music distribution. (Hardly surprising since music distribution was the root of P2P filesharing after all.) The late AudioGalaxy - one of the P2P filesharing pioneers - had a system where you could set other users as friends, and join music clubs.
    Users marked up that way could put songs on your queue, and so you could get up in the morning to find your hard driver more or less full with new music you didn't actually request yourself, but which was "pushed" onto your computer by other users sharing your taste in music. It was a neat concept. Obviously, it had room for abuse - someone you prematurely gave permission could spam your hard driver with junk, but generally systems like this work fairly well since the community gets rid of such idiots pretty fast.

    --
    Switch back to Slashdot's D1 system.
  4. Re:Screw multimedia; how about software? by micromoog · · Score: 2, Informative
    no, W.U. has all three options:
    1. don't do shit
    2. download but don't install
    3. download and install.
  5. Re:I liked it better... by Divide+By+Zero · · Score: 4, Informative

    Seriously, this sounds like a traditional IRC channel with XDCC bots.

    The difference between this and IRC fserv bots is important: kast/konspire (I dont' know which - seems the two are related) are server push.

    On fservs, you still have to go out, look for what you want, try to figure out who has it, download it, and then see if it's what you want.

    The new tool in question delivers content to your computer without your interaction. The analogy to broadcasting was right on: Somebody else decides what you want to / get to see, then you tune in to the appropriate channel and the content is delivered without you having to do anything.

    It has a few inherent problems, absolute trust of the sender being the biggest that I can see. I have to trust whoever's running the channel not to send me kiddie pr0n and then call the FBI on me. Disk quotas (don't send me more than m megs per n hours, or perhaps don't let my incoming directory grow to larger than x megs) would be a good thing to have, and I don't know if it's been implemented here or not.

    It has potential, though. News services, shareware-of-the-day services, new-song-of-the-day services (generate buzz about new bands), etc etc. I'll look at it, but I'll be wary about it.

    --
    Dare to Hope. Prepare to be Disappointed.
  6. Re:C++? by Zathrus · · Score: 4, Informative

    Let's face it, languages with security features are more suitable for servers.

    Uh, exactly what security features are you looking for?

    I'm assuming you're going to be using the STL... if you're not, well then I hope you're not planning on using any Perl modules or Python libraries either, because otherwise you're really comparing apples and oranges (not that you aren't already, but that's another discussion).

    std::string and std::vector take care of most of the security concerns you might have -- presuming you use them properly of course. If you need to deal with pointers and std::auto_ptr isn't useful (which, in general, it's not) then use a smart pointer library -- I highly recommend Boost - I've used it's shared_ptr class and like it. In over a year of serious C++ development we've had exactly one memory related problem -- and that was from me misusing boost (and suspecting I was doing so during development but forgetting about it during testing).

    The general concerns with C/C++ are buffer overruns and other memory stomps. If you use the right libraries it's not an issue in either (go look at vsftpd's string functions for an example of what I'm talking about in C). If you're writing insecure C++ code then it's most likely because you're ignoring significant language features (like the STL). It's not a language issue.

  7. Re:Screw multimedia; how about software? by 42forty-two42 · · Score: 4, Informative

    You can crontab emerge --fetchonly -u world, that'll download updates automatically. But this system's more scalable.

  8. Re:Something I don't understand by Jhan · · Score: 2, Informative

    Eh? That's me. I published four movies and set them to repeat weekly (sort of a stress test...). What are you seing?

    --

    I choose to remain celibate, like my father and his father before him.

  9. Re:C++? by cras · · Score: 4, Informative
    The general concerns with C/C++ are buffer overruns and other memory stomps. If you use the right libraries it's not an issue in either (go look at vsftpd's string functions for an example of what I'm talking about in C). If you're writing insecure C++ code then it's most likely because you're ignoring significant language features (like the STL). It's not a language issue.

    Yes, I fully agree. vsftpd is one of the best examples of how to write secure C. As for Kast .. I briefly checked the sources, it's using a lot of code such as:

    foo = new[ strlen(bar) + 100 ]; sprintf(foo, "stuff %s", bar);

    Which is safe only as long as you're careful. And was the author careful enough? No. I'm not touching this thing until the sprintf()s are gone.

  10. Not big a deal,unless implemented from scratch... by Anonymous Coward · · Score: 1, Informative

    A person with CORBA experience will recognize this as a service using the "canonical push model"
    of the OMG Event Service -- see page 932 of Advanced CORBA Programming with C++ by Henning and Vinosky.
    (actually, the OMG Notification Service would probably be used for this since filtering and quality of service issues are better addressed with that service.)
    A service like this can be easily written in CORBA, and if utilizing the ACE and TAO frameworks, can be written in a cross-platform and portable manner.
    Although CORBA, ACE, and TAO do have high learning curves, their use can greatly simplify the creation of projects like this, since most of an application
    like this is boilerplate code. Please don't re-invent the wheel, the use of high quality application frameworks can save yourself much time.
    In fact, this application would probably be considered a "Hello World" program for the CORBA Event or Notification Service.