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)
Pushing files, huh? It's as bad as pushing drugs. Into jail, my little hacker-bee.
Sig for sale or rent. One previous user. Inquire within.
Now I don't have to manually download crappy rips of my favorite songs, I can have them forced upon me! :-)
Actually, this looks like a cool idea. The fact that it's a sourceforge project only makes it better!
Five Dolla Moddy-Moddy?
...when it was called IRC. Seriously, this sounds like a traditional IRC channel with XDCC bots. Decentralized (many servers on the same net comprising a single channel) and varied (you can have many varied channels). I mean, it sounds like a cool idea, and a neat proof-of-concept, but is it really needed or useful?
I think that web based interfaces are severly underrated in their potential because of the reason mentioned. I love the new thinking being employed throughout this project.
Cheap $3 hosting plans
now I don't have to search for porn, porn comes to me.
Je t'aime Stéphanie
I am not interested in "pushed" multimedia, but imagine having your Gentoo packages already pre-fetched for you, whenever there's an update? Emerge and it just starts compiling w/out the download step. Mmmm...
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
Am I to understand you start it up, go to bed, and wakeup to having a buncha unknown files on your computer? And this is a good thing?
I'm gonna try it now!
Luck favors the prepared, darling.
Especially since in this network, whoever distributes a given file also requested it (at least that's what I am reading out of the documentation), in contrast to other networks, eg. freenet where the fact that you have data on your HD and distribute it to other people does not imply that you requested that data to be there yourself.
(Note: I still think this is a pretty neat concept, though!)
Switch back to Slashdot's D1 system.
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
without konspire: 8 hours d/ling, compiling software
with konspire: 7h55m compiling software
Wohoo!
(Any input given would be gratefully received btw)
Get your own free personal location tracker
But I refuse to download anything from a website with a black background.
But for server apps, I think it's the wrong choice.
Maybe, but my personal opinion is that in the end it's better to write an application in a language you know really well (but might not be the best thing) than write some hacky fudge job (which will no doubt be really flakey and possibly even more insecure) in a language you don't know just because it's the best one to use.
Avantslash - View Slashdot cleanly on your mobile phone.
I'd like to request an invitation to your group. I have a great many high quality files, adequate bandwith, and I promise never to do anything to harm the group.
Thanks,
Hillary Rosen
-- Fighting mediocrity one bad post at a time.
Hell, with push technology, they could just create pirates on the fly as needed.
*hands shaking...*
Ok, write this down. 12.225.189.24
I love you.
Any sufficiently well-organized Government is indistinguishable from bullshit.
So you call it konspire, eh? And this helps the P2P keiretsu allay the fears of the music industry that it's not all about ripping them off how, exactly?
You P2P guys really crack me up.
-Shane
I love teh int4rw3b!!!!!111one1
I've got all this pr0n, and all this bandwidth... but no IPs to share it with.
I believe this is a first for humanity. Sort of like why you never hear the statement, "Man! What am I going to do with all these drugs?"
This is a retrograde step.
It turns p2p file downloading into a "tv-like" experience where you have to be online at the right time to get the file.
Sure, you could probably script it so you get the files, but that makes it like tivo where you can watch programmes when you want but you have to remember to set it up so it records it in the first place.
We have evolved beyond that. Now, with p2p you can search for and download whatever you want, when you want. OK, so someone still has to be sharing it, which is less likely with older stuff, but there are starting to be Farenheit-451-like sharers out there (myself included) who are keeping one thing (e.g. a favourite anime series) alive by always sharing it.
Also, there is a significant barrier to adoption of a new p2p-like app. You have your p2p working fine, and downloading well, then you are expected to start using a new one. You don't know how it works yet, let alone how to optimize it or where to get what you want; you know that everyone else faces the same hurdles so there won't be much content for a while, if at all.
This wouldn't be so bad if you could try out a new p2p app while using an old one, but you really need to dedicate all your bandwidth to a program to make the most of it.
At the moment emule is where it's at (at least for me), and I won't stop using it unless everyone else does and the sources dry up.
graspee
The concept of konspire is really cool. It provides a good method of anonymity of the original sender. Pesonally I'd like to see it use the bittorrent method of file delivery because you have the potential of only having to send the whole file once, plus if konspire decides to send the file to a 28.8k modem user first, everybody else will have to wait until that user gets the file before they can receive it, where as bittorrent's method can send to many people simultaneously and still use less bandwidth. The problem with bittorrent is that you know who sent the original files, because you got the .torrent from them, so a combination of both technologies would rule!
I'm not a real doctor, but I recommend beer.
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.
When does the technology get pervasive enough to start warranting more useful apps built on top of P2P? Like a way to post resumes, jobs, RFPs, etc.. and be able to query/respond... without needing the 400 job boards out there. Or code snippets, or news services that can survive massive overloads ala 9/11?
meh
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.
So to any given node it is unknown whether the node it's receiving a transmission is the original distributor. But still, the node it is receiving from is a distributor - that's just as illegal, at least in the context of copyright protected works. Especially since in this network, whoever distributes a given file also requested it (at least that's what I am reading out of the documentation), in contrast to other networks, eg. freenet where the fact that you have data on your HD and distribute it to other people does not imply that you requested that data to be there yourself.
...but as a direct consequence of knowing what is in your share, or at least the ability to know that (that is, only the things you're subscribing to). Open relays don't get sued for fraud, 0 day hacked warez servers don't get sued for piracy (arr!) and your DDoS host doesn't get sued for launching DoS attacks because they did not know what was being routed through them.
Freenet is basicly trying to make everyone (except the inserter and the requester, which are difficult to find) be a common carrier (ISPs do caching, so the fact that Freenet caches stuff does not prevent this). Whether that argument will stand up in court is questionable, but this system certainly won't hold up to this defense.
Kjella
Live today, because you never know what tomorrow brings
according to the directions I think you're supposed to go to bed now
I can think of lots of uses for this system (ie. other than MP3 and porn). The gaming community in particular could really benefit. I used to run a review site for user-created Half-Life maps called radium. I would have loved to have this around back then. I could have advertised a kast channel people could subscribe to to receive new maps as they came out. Could even push out a file with a link to the accompanying review, or maybe just send the review itself, or maybe just send a few screenshots and a summary and a download link.
:)
Anyways, I think its a really cool concept. Its been crashing on me a bit though, so hopefully it stabilizes and gains acceptance.
Security features in a language attempt (poorly in most cases) to substitute for the programmer having an adequate security mindset. If you rely on the security features of a language, then you're screwed if they're broken. You're relying on the security auditing that has been performed on that language's features, and committing yourself to live or die by it. Have you personally verified that that language's seecurity features are designed well, and strong enough to meet your security requirements? Has someone you trust done so and published the results? If not, why are you relying on it?
My advice is go the opposite direction. Learn about security from a programmer perspective. Accept only libraries and components that have been extensively audited by knowledgeable, trusted sources. Then build your server on top of them in a lower level language that affords you the ability to take direct charge of everything else. Make your server secure by thinking about security in every line you code.
I use C, but the exact choice of language isn't important; the mindset and approach is. This advice applies equally to any other language: Check the return value from EVERY system call, EVERY resource allocation, and EVERY library call. Verify ALL inputs before using them, both for length and for sanity of contents. Before EACH time you write something to any kind of buffer, check that you won't write past the end FIRST. Do all of these things in every function of every module of every application. And if you rely on a language or library feature instead of doing it yourself, you'd better be damn sure that the language or library feature is doing it correctly and completely -- VERIFY this before you deploy your program.
Some may call writing in C a security risk. Inherently, it isn't. C just gives the programmer more rope to either make a better knot or make a better noose, as they see fit. The first ten to twenty lines of nearly every C function I write go like this: return failure if this parameter isn't sane; return failure if that parameter isn't sane; return failure if any persistent context isn't consistent with how we were called; try to allocate all resources required for the function and return failure if any of those allocations failed. Some other languages may automate some of that. But as a security auditor, I'm going to want to see all that. If I can't see it, I'm going to want to examine in detail the implementation of the language features that do it implicitly. If I can't do that, then I can't consider the program secure. Using C helps me audit my code because it forces all security measures to be explicit and spelled out in detail. Yes, that's more work for the programmer. But it's less work and more certainty for the security auditor. That's a tradeoff I'm willing to make.
-----Chaz
"Needles," it reasoned, "often contain medicine."
And, so reasoning, it jammed the rusty needle directly into its ass.
Moral of the story:
Basically, you click on a link which will subscribe the peer to the channel, and the peer will automatically download/pre-cache any new items that are added to the RSS feed.
You simply have to create an RSS feed and create a link that converts that feed into a channel that is subscribable via the Open Content Network. I've set up an example of a movie trailer RSS feed here And have linked it into the Open Content Network here.
This could be handy for people who can't watch their favorite teams because they don't live where the games are shown on TV. I'd love to have Tottenham games on my hd every Sunday morning. Or various European qualifiers they don't show on TV in the States.
If someone can put Larsson's 2 goals from today somewhere I'd appreciate it too.