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."
← Back to Stories (view on slashdot.org)
a combination of this and torrent.
.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.
.torrent mesh features would be really nice.
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.
so anyway, this with
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.
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.
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.
You can crontab emerge --fetchonly -u world, that'll download updates automatically. But this system's more scalable.
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.