[PHP] Peer-2-Peer

[RedHat]

Hallo,

Ik wil een idee uitwerken op kleinschalige basis. Ik wil een Peer-to-peer programma maken, dit geheel webbased Nu zijn er natuurlijk een hoop limitaties. De grootste is: hoe access je de files. Hiervoor is denk ik een browserplugin nodig die de brug vormt tussen de gui/php > files.

Nu heb ik e.e.a. gelezen, maar voornamelijk over ActiveX. ActiveX is IE only en dus eigenlijk geen optie. Dus dan zou je misschien een installer moeten maken die e.e.a. verzorgt. Maar met de hedendaagse technologiën moet dit volgens mij makkelijker kunnen.

Ik heb één zo'n project gezien: Heb de maker gemailt alleen helaas geen reactie gekregen.
Misschien iemand die mij op weg kan helpen? Een duwtje in de goede richting?

In mijn zoektocht op google (keywoards: p2p, webbased, php) kwam ik niet veel verder dan ActiveX.

Het gaat er dus om dat mensen een folder kan 'sharen'. Die folder moet doorgegeven worden aan PHP. Op het moment dat iemand anders de file aanklikt dan moet je dus bij de tegenpartij de file downloaden. Het idee lijkt me duidelijk. Ik hoef absoluut geen kant en klare oplossingen, het is meer de vraag of dit überhaubt kan en in welke richting ik moet gaan zoeken.

[Osiris]

Naar mijn weten kan iedere veilige browser zélf geen files op de hardeschijf aanspreken, m.u.v. de <input type="file">-tag.

[RedHat]

Osiris schreef op woensdag 23 september 2009 @ 19:58:
Naar mijn weten kan iedere veilige browser zélf geen files op de hardeschijf aanspreken, m.u.v. de <input type="file">-tag.

Dat kan wel. Kijk maar naar Housecall etc die je files scant op virussen. Daar zijn natuurlijk wel plugins voor nodig. Maar goed. Dat is dan ook concreet mijn vraag; in welke hoek moet ik gaan zoeken

Er zullen wel een hele hoop limitaties zijn denk ik. Files resumen, hoe ga je dat doen. En zo nog honderd dingen waar je tegenaan kan lopen. Maar goed, first things first.

[ Voor 16% gewijzigd door RedHat op 23-09-2009 20:04 ]

[ieperlingetje]

iets met java applets of flash gaan proberen ? Die hebben naa toestemming van de gebruiker toegang tot het filesystem.

[RedHat]

ieperlingetje schreef op woensdag 23 september 2009 @ 20:14:
iets met java applets of flash gaan proberen ? Die hebben naa toestemming van de gebruiker toegang tot het filesystem.

Ik kan inderdaad eens naar Java Applets kijken. Ik heb zelf weinig kaas gegeten van Java. Maar Java Applets is toch een opzichzelfstaand iets? Dus dat kan niet (goed) communiceren met PHP? Op b.v. hotscripts kan ik weinig vinden.... Zeg maar helemaal niets. Dus ik denk eigenlijk dat wat ik wil toch wel uniek is... Misschien wel zelfs niet haalbaar

[ Voor 16% gewijzigd door RedHat op 23-09-2009 20:20 ]

[Osiris]

RedHat schreef op woensdag 23 september 2009 @ 20:16:
[...]

Ik kan inderdaad eens naar Java Applets kijken. Ik heb zelf weinig kaas gegeten van Java. Maar Java Applets is toch een opzichzelfstaand iets? Dus dat kan niet (goed) communiceren met PHP? Op b.v. hotscripts kan ik weinig vinden.... Zeg maar helemaal niets. Dus ik denk eigenlijk dat wat ik wil toch wel uniek is... Misschien wel zelfs niet haalbaar

Hoezo zou het niet goed kunnen communiceren met PHP? Dat verloopt toch allemaal via HTTP-requests naar ik aanneem? En hoezo zou Java dat niet kunnen?

[RedHat]

Osiris schreef op woensdag 23 september 2009 @ 20:21:
[...]

Hoezo zou het niet goed kunnen communiceren met PHP? Dat verloopt toch allemaal via HTTP-requests naar ik aanneem? En hoezo zou Java dat niet kunnen?

Zoals ik al zei heb ik daar geen kaas van gegeten. De vraagteken staat er dan ook omdat het een vraagstelling is. Een vraagstelling betekend niet dat je iets zegt maar dat je iets vraagt. Omdat ik geen kaas gegeten heb van java(applets), en ik bar weinig kan vinden in deze materie (zeg maar helemaal niets) wilde ik van mijn aanname een vraagstelling maken, wat ik ook gedaan heb.

[Osiris]

Ik ben slechts benieuwd naar de herkomst van die aanname. Al vind ik het wel vreemd om een vraagstelling te maken waarbij je nogal duidelijk kenbaar maakt dat het volgens jou niet kan. Vraag dan gewoon of het wel of niet kan als je er geen snars van snapt

En de relatie met hotscripts snap ik ook niet echt. Je zocht daar op PHP-scripts naar ik aanneem?

Sowieso snap ik niet 100% wat je met PHP wil doen? Moet dat functioneren als tracker ofzo?

[ Voor 27% gewijzigd door Osiris op 23-09-2009 20:32 ]

[RayNbow]

RedHat schreef op woensdag 23 september 2009 @ 19:56:
Hallo,

Ik wil een idee uitwerken op kleinschalige basis. Ik wil een Peer-to-peer programma maken, dit geheel webbased Nu zijn er natuurlijk een hoop limitaties. De grootste is: hoe access je de files.

Dat lijkt me niet je grootste probleem. Wat dacht je van de enorm hoge churn? Zodra een gebruiker z'n web browser afsluit is ie niet meer actief in de P2P overlay. Heb je hier al over nagedacht?

[RedHat]

Osiris schreef op woensdag 23 september 2009 @ 20:31:
Ik ben slechts benieuwd naar de herkomst van die aanname. Al vind ik het wel vreemd om een vraagstelling te maken waarbij je nogal duidelijk kenbaar maakt dat het volgens jou niet kan. Vraag dan gewoon of het wel of niet kan als je er geen snars van snapt

En de relatie met hotscripts snap ik ook niet echt. Je zocht daar op PHP-scripts naar ik aanneem?

Sowieso snap ik niet 100% wat je met PHP wil doen? Moet dat functioneren als tracker ofzo?

Op bovenstaande ga ik geeneens reageren.

De realtie met hotscripts: Ik ben dus opzoek gegaan of er ooit iemand in geslaagd is iets met P2P te doen (via java applet of via iets anders). Omdat Hotscripts een verzamelsite is van zowel commerciele als niet commerciele producten is dat een goed beginpunt om te kijken of er al zoiets bestaat.

En wat ik met PHP wil doen? Ik geef duidelijk aan in startpost dat mensen moeten inloggen. En er zijn naast P2P een hoop andere functies in PHP die te gebruiken zijn. Maar dit staat geheel lost van de hoofdvraag.

Dat lijkt me niet je grootste probleem. Wat dacht je van de enorm hoge churn? Zodra een gebruiker z'n web browser afsluit is ie niet meer actief in de P2P overlay. Heb je hier al over nagedacht?

Hier ben ik mij weldegelijk bewust van. Het is dan ook meer een kleinschalig project om te kijken of dit ooit al is gedaan, en natuurlijk of het überhaubt mogelijk is.

[ Voor 14% gewijzigd door RedHat op 23-09-2009 20:37 ]

[Verwijderd]

Maak gewoon gebruik van het torrent protocol, zet dus zelf een (bit)torrent server op. Je moet zoveel mogelijk gebruik maken van de oplossingen (open standaarden?) die er al zijn .

Zie ook Wikipedia: Private peer-to-peer

[RedHat]

Verwijderd schreef op woensdag 23 september 2009 @ 20:37:
Maak gewoon gebruik van het torrent protocol, zet dus zelf een (bit)torrent server op. Je moet zoveel mogelijk gebruik maken van de oplossingen (open standaarden?) die er al zijn .

Zie ook Wikipedia: Private peer-to-peer

Dat is geen optie IMHO. Ik wil specifiek iets bewerkstelligen.

[Foxl]

Het zal er dus op neer komen dat je een plugin zult moeten schrijven om de link PC -> Server te maken. Dit in combinatie met het feit dat de gebruiker hiervoor altijd zijn browser open zal heb moeten staan maakt het logisch om het project buiten de browser om te laten werken, waarbij je dus een gewone P2P client overhoud..

Maar als je het bij wijze van "expiriment" toch in elkaar wilt knutselen lijkt me een Flash of Java oplossing het meest voor de hand liggende. Aangezien je aangeeft daar nog weinig kaas van te hebben gegeten lijkt me dit een uitgesproken moment om je daar eens in te verdiepen..

[RedHat]

Foxl schreef op woensdag 23 september 2009 @ 20:44:
Het zal er dus op neer komen dat je een plugin zult moeten schrijven om de link PC -> Server te maken. Dit in combinatie met het feit dat de gebruiker hiervoor altijd zijn browser open zal heb moeten staan maakt het logisch om het project buiten de browser om te laten werken, waarbij je dus een gewone P2P client overhoud..

Maar als je het bij wijze van "expiriment" toch in elkaar wilt knutselen lijkt me een Flash of Java oplossing het meest voor de hand liggende. Aangezien je aangeeft daar nog weinig kaas van te hebben gegeten lijkt me dit een uitgesproken moment om je daar eens in te verdiepen..

Mja. Maar mijn idee was dus een volledig "webbased" client (dus zonder flash iig). In Java kan ik mij evt wel verdiepen. Maar goed, het meest ultieme was natuurlijk via een soort van browserplugin de overdracht te doen.

Java als "softwareplatform" ken ik overigens wel. Niet héél bedreven in, maar ken het wel. Toch praat je dan over een opzichzelfstaand platform en niet meer over webbased.

[ Voor 8% gewijzigd door RedHat op 23-09-2009 20:51 ]

[Osiris]

Wat wil je precies met het hele "webbased" dan? Want in principe zit je sowieso vast aan een plugin en is er verder maar weinig communicatie met een eventuele webserver (inloggen, file-info uitwisselen hooguit). De rest gaat allemaal, ba-da-tsjing, via peer-2-peer. Dus zoveel 'web' is er niet bij en is Java net zo goed een plugin voor je 'web'-browser.

[RedHat]

Osiris schreef op woensdag 23 september 2009 @ 20:59:
Wat wil je precies met het hele "webbased" dan? Want in principe zit je sowieso vast aan een plugin en is er verder maar weinig communicatie met een eventuele webserver (inloggen, file-info uitwisselen hooguit). De rest gaat allemaal, ba-da-tsjing, via peer-2-peer. Dus zoveel 'web' is er niet bij en is Java net zo goed een plugin voor je 'web'-browser.

Ja dat is mij nu duidelijk. Dan zal het toch iets in java worden. Achja, kan ik de boeken weer uit de kast halen Maarja, de essentie is er dan wel 'vanaf'. Kun je net zogoed een standalone app bakken

[HaTe]

Kijk eens naar Gears van Google. Volgens mij moet het hier wel mee kunnen deze kan oog wel een link maken tussen server en pc.

[Verwijderd]

Is dit niet zoiets als http://jetbytes.com/?

[Tead]

Wil je niet zoiets maken als uTorrent + webui of torrentflux? Dit zijn beide p2p clients met een web interface. Fysiek komt er dan gewoon een app te draaien buiten de browser om en deze kan je via je browser benaderen/beheren. Alles lijkt dan via de browser te gaan, echter bij het afsluiten van je browser gaat alles gewoon door.

[Janoz]

Wanneer je een zoveel mogelijk webbased oplossing voor ogen had, hoe had je je dan überhaupt het hele "peer naar peer" gedeelte voorgesteld? Ik neem aan dat je begrijpt dat 1 van de belangrijkste eigenschappen van php is dat de logica op de server uitgevoerd wordt. Dan kun je vervolgens wel terugkrabbelen door te zeggen dat je alsnog logica op de client uit gaat voeren middels een java applet, maar dan zul je alleen maar tegen security problemen op gaan lopen wanneer je een verbinding wilt leggen met een andere computer dan de server.

Mijn allergrootste vraag blijft: Welk probleem denk je überhaupt op te gaan lossen?

[RedHat]

Janoz schreef op woensdag 23 september 2009 @ 22:51:
Wanneer je een zoveel mogelijk webbased oplossing voor ogen had, hoe had je je dan überhaupt het hele "peer naar peer" gedeelte voorgesteld? Ik neem aan dat je begrijpt dat 1 van de belangrijkste eigenschappen van php is dat de logica op de server uitgevoerd wordt. Dan kun je vervolgens wel terugkrabbelen door te zeggen dat je alsnog logica op de client uit gaat voeren middels een java applet, maar dan zul je alleen maar tegen security problemen op gaan lopen wanneer je een verbinding wilt leggen met een andere computer dan de server.

Mijn allergrootste vraag blijft: Welk probleem denk je überhaupt op te gaan lossen?

De verbinding tussen 2 clients. Of eigenlijk; Client <> Server <> Client.
Ik zat meer te denken aan een kleine plugin voor de browser. Die het dus mogelijk maakt files uit te lezen op een locatie die de gebruiker authoriseerd.

[Gomez12]

Client<>server<>client is nog wel redelijk te versieren met een client die via een java-applet de data verstuurd naar een server-side process ( php lijkt me niet handig omdat die volgens mij niet aan de binnenkomende datastream iets kan doen, dus ook niet live doorzetten, dan krijg je meer upload-> php -> download idee, kan ook maar de ontvangende kant zit dan te wachten op de upload en daarna op de download... )

Maar dit kost je wel een berg traffic op je server ( elk bestand veroorzaakt 2x traffic, inkomen en uitgaand )

Echt p2p is het snelste / efficientste, maar dan moet je weer firewalls etc kunnen doorbreken zodat de client direct contact met de server kan hebben ( plus dat je geen server0side controle meer hebt )

Wat wil je precies?

[qless]

Sorry, ik vindt het een raar idee. p2p is (per definitie) bedoeld als peer 2 peer, dus zonder server, directe communicatie tussen clients. Het hele idee van dan een server ertussen plaatsen maakt het meer een soort ftp/file server.

[Matis]

qless schreef op donderdag 24 september 2009 @ 08:39:
Sorry, ik vindt het een raar idee. p2p is (per definitie) bedoeld als peer 2 peer, dus zonder server, directe communicatie tussen clients. Het hele idee van dan een server ertussen plaatsen maakt het meer een soort ftp/file server.

Klopt, en met een beetje soap/xml-rpc kun je vanuit de server de andere peer pushen voor een bestand oid.

[Woy]

Matis schreef op donderdag 24 september 2009 @ 08:42:
[...]

Klopt, en met een beetje soap/xml-rpc kun je vanuit de server de andere peer pushen voor een bestand oid.

Maar dan is het geen peer to peer meer, maar client-server based.

[Matis]

Woy schreef op donderdag 24 september 2009 @ 08:56:
Maar dan is het geen peer to peer meer, maar client-server based.

Klopt!

RedHat schreef op woensdag 23 september 2009 @ 23:09:
De verbinding tussen 2 clients. Of eigenlijk; Client <> Server <> Client.
Ik zat meer te denken aan een kleine plugin voor de browser. Die het dus mogelijk maakt files uit te lezen op een locatie die de gebruiker authoriseerd.

Want RedHat geeft aan dat het ook geen p2p is/gaat worden.

[ Voor 4% gewijzigd door Matis op 24-09-2009 09:01 ]

[E-Vix]

p2p in php gaat je niet lukken. Zoals al gezegd is is php een server side taal en kan deze niets op de client uitvoeren. Een browserplugin zal ook niet gaan werken. Je kwam immers zelf al met de opmerking dat ActiveX uitgesloten was omdat dat alleen maar op IE werkt. Dit geld voor alle browserplugins. Een plugin voor FireFox werkt alleen op FireFox, en dat geld ook voor alle andere browsers. Als je het wel met een plugin wilt gaan doen, dan zal je voor iedere browser een aparte plugin moeten gaan schrijven.
De enige twee opties die er over blijven zijn Flash en Java. En dan bedoel ik Java als in een Java applet, en niet als in een Javascript. Javascript is welliswaar wel client side, maar is in mijn mening niet krachtig genoeg om daarmee een verbinding op te bouwen met een andere computer. Je zal namelijk socket verbindingen o.i.d. moeten gaan opzetten etc. en dat lukt je simpelweg niet in Javascript. Ook voor Java en Flash heb je weer een plugin nodig, maar deze plugin is voor alle browsers beschikbaar, en wordt door een 3e partij gemaakt. Bovendien zijn deze plugins op veel computers al geïnstalleerd.
De enige twee keuzes die je hebt zijn dus Java of Flash. Je zegt dat je van alletwee geen kaas hebt gegeten, dus in feite zou het niet uit mogen maken welke van de twee je gaat gebruiken.
P2P , oftewel peer to peer, betekend letterlijk dat een client rechtstreeks een verbinding maakt met een andere client zonder dat daar nog een server tussen zit. Het enige waarvoor er nog kort een server tussen zou kunnen zitten is voor het opzetten van de initiële connectie. Oftewel, je client maakt verbinding met de server. De server zegt welke bestanden er beschikbaar zijn. De client zegt tegen de server dat hij bestand 'a' zou willen hebben, en de server zegt vervolgens tegen de client dat hij voor bestand 'a' verbinding moet maken met client '2'. Vanaf dat moment valt de verbinding met de server weg en gaan de clients onderling verder. In feite is dit ook hoe bittorrent ongeveer werkt.
Azureus, een bekende bittorrent client, is volledig in Java geschreven. De broncode is volgens mij ook beschikbaar, dus je zou daar eens naar kunnen kijken. Er zijn meerdere Java bittorrent clients beschikbaar, dus daar kan je vast wel iets in vinden.

[RedHat]

Dat is dus ook de bedoeling. Want echt Peer-To-Peer wordt wel heel lastig.
Nee, de sever managed de connecties, de bestandsoverdracht is wel peer-2-peer. Maar bij alle peer-2-peer protocollen die ik ken heeft de server een management-functie. Is het dan geen peer-2-peer meer? Das natuurlijk onzin. De server 'harvest' de bestanden en maakt ze publiek. Als iemand op een bestand klikt wordt er gekeken welk ip daar achter schuil gaat, en de server geeft client1 en client2 een commando zodat de overdracht tussen client1 en client2 kan starten. Vanaf dat punt is het werk van de server gedaan.

De enige oplossing is eigenlijk een java-applet of flash. Na researchen ben ik erachter gekomen dat zoiets in java niet vaak is gedaan. Ik zal dus mijn javaskills moeten bijspijkeren en weer wat boeken uit de kast moeten trekken

Het hele idee was ook meer een idee die ik kleinschalig werkelijkheid wou maken; gewoon om te zien of het werkt en hoe het werkt. Het is natuurlijk mooi om bestanden te kunnen 'sharen' via een webbased protocol. Het moet ook easy-peasy zijn. Je start de website in, logt in, geeft aan welke bestanden je wit delen en je kunt gaan.

Je komt tegen véél meer problemen aan, maar als opzetje is het natuurlijk een erg leuk project. Het wordt er alleen niet makkelijker op dat Firefox een groot aandeel heeft. Anders zou je met ActiveX een simpel iets in elkaar kunnen schroeven en tadaa. Dat zal nu dus iets worden wat door meerdere platformen en browsers ondersteunt moet worden; java & flash dus. Maar wat als iemand zijn browser afsluit; zijn sessie zal x tijd doorlopen. Wat als iemand op 99% vvan de download uitlogt, kun je hem dan resumen, en zoja kan dat bij een andere gebruiker. Dit zijn allemaal features die er niet hoeven te komen en waarover ik dus (nog) niet nadenk

Erg leuk project waar ik mij in ga verdiepen. De simpelheid is de keyword. Less=More. Ik ga mij in ieder geval nog meer diepen in de materie.

Mochten jullie nog bepaalde dingen weten, over verbindingen opzetten etc, of daar iets van een tutorial voor hebben, of informatie over dit fenomeen voel je dan vrij om dat te posten Maandag ga ik namelijk een aantal Java boeken lezen/herbeleven

[ Voor 45% gewijzigd door RedHat op 24-09-2009 10:14 ]

[Woy]

RedHat schreef op donderdag 24 september 2009 @ 10:07:
Dat is dus ook de bedoeling. Want echt Peer-To-Peer wordt wel heel lastig.
Nee, de sever managed de connecties, de bestandsoverdracht is wel peer-2-peer. Maar bij alle peer-2-peer protocollen die ik ken heeft de server een management-functie. Is het dan geen peer-2-peer meer? Das natuurlijk onzin. De server 'harvest' de bestanden en maakt ze publiek. Als iemand op een bestand klikt wordt er gekeken welk ip daar achter schuil gaat, en de server geeft client1 en client2 een commando zodat de overdracht tussen client1 en client2 kan starten. Vanaf dat punt is het werk van de server gedaan.

De enige oplossing is eigenlijk een java-applet of flash. Na researchen ben ik erachter gekomen dat zoiets in java niet vaak is gedaan. Ik zal dus mijn javaskills moeten bijspijkeren en weer wat boeken uit de kast moeten trekken

Met die opzet ga je ook met Java en flash applicaties in de problemen komen volgens mij. Ook met een Java applet mag je niet zomaar naar andere hosts verbinden dan de server waar de applet vandaan komt. Het zou misschien kunnen dat je die permissies wel kunt krijgen, maar uiteindelijk kun je dan volgens mij net zo goed gewoon een stand-alone applicatie maken, waarvan je de installer op een web-site knalt.

[Matis]

Ik weet niet of je bekend met dropbox? http://www.getdropbox.com/tour Ik dacht eerst dat je zoiets wilde maken.

Het *eenvoudigste* lijkt mij een soort van fileserver; zie: Verwijderd in "[PHP] Peer-2-Peer"

[Janoz]

RedHat schreef op donderdag 24 september 2009 @ 10:07:
Dat is dus ook de bedoeling. Want echt Peer-To-Peer wordt wel heel lastig.
Nee, de sever managed de connecties, de bestandsoverdracht is wel peer-2-peer. Maar bij alle peer-2-peer protocollen die ik ken heeft de server een management-functie. Is het dan geen peer-2-peer meer? Das natuurlijk onzin. De server 'harvest' de bestanden en maakt ze publiek. Als iemand op een bestand klikt wordt er gekeken welk ip daar achter schuil gaat, en de server geeft client1 en client2 een commando zodat de overdracht tussen client1 en client2 kan starten. Vanaf dat punt is het werk van de server gedaan.

De essentie van p2p is dat clients zelf onderling hun data uitwisselen. Het is inderdaad zo dat de servers over het algemeen als enige functie hebben om de clients van elkaars bestaan te laten weten.

De enige oplossing is eigenlijk een java-applet of flash. Na researchen ben ik erachter gekomen dat zoiets in java niet vaak is gedaan. Ik zal dus mijn javaskills moeten bijspijkeren en weer wat boeken uit de kast moeten trekken

Er is een reden waarom dit met een applet eigenlijk nog niet gedaan is (Wel met een applicatie. Limewire en Azeurus zijn voorbeelden van p2p clients geschreven in java)

Het hele idee was ook meer een idee die ik kleinschalig werkelijkheid wou maken; gewoon om te zien of het werkt en hoe het werkt. Het is natuurlijk mooi om bestanden te kunnen 'sharen' via een webbased protocol. Het moet ook easy-peasy zijn. Je start de website in, logt in, geeft aan welke bestanden je wit delen en je kunt gaan.

Wat is er uberhaupt nog webbased aan het protocol wanneer clients onderling een socket op gaan zetten? Of was je van plan om een webserver te gaan integreren in je java applets?

Je komt tegen véél meer problemen aan, maar als opzetje is het natuurlijk een erg leuk project. Het wordt er alleen niet makkelijker op dat Firefox een groot aandeel heeft. Anders zou je met ActiveX een simpel iets in elkaar kunnen schroeven en tadaa. Dat zal nu dus iets worden wat door meerdere platformen en browsers ondersteunt moet worden; java & flash dus. Maar wat als iemand zijn browser afsluit; zijn sessie zal x tijd doorlopen. Wat als iemand op 99% vvan de download uitlogt, kun je hem dan resumen, en zoja kan dat bij een andere gebruiker. Dit zijn allemaal features die er niet hoeven te komen en waarover ik dus (nog) niet nadenk

Het punt is dat je hele idee gewoon niet klopt. Je start met het idee om p2p webbased te doen, maar zult langzaam tot de conclusie komen dat het enige waar je mee bezig bent gewoon een client applicatie maken. Daarbij zul je dezelfde problemen tegenkomen die losstaande applicaties ook hebben zoals firewalls en clients in een NAT omgeving. Daar bovenop introduceer je ook nog eens wat extra moeilijkheden doordat je je clients in een sandbox omgeving wilt laten draaien (want in de browser) waardoor je standaard geen toegang hebt tot het file systeem, niet de mogelijkheid krijgt om te verbinden met een andere client en al helemaal geen serversocket kunt openen om de aanvraag van een andere client te kunnen ontvangen.

Erg leuk project waar ik mij in ga verdiepen. De simpelheid is de keyword. Less=More. Ik ga mij in ieder geval nog meer diepen in de materie.

Laat dat simpel maar weg. Wat jij probeert te doen is een redelijk ingewikkeld probleem oplossen (het schrijven van een p2p client) waarbij je vervolgens nog eens een enorme bak extra beperkingen toevoegt zonder dat dit ook maar 1 voordeel oplevert. Sterker nog, het wordt eerder gebruikers onvriendelijker.

Mochten jullie nog bepaalde dingen weten, over verbindingen opzetten etc, of daar iets van een tutorial voor hebben, of informatie over dit fenomeen voel je dan vrij om dat te posten Maandag ga ik namelijk een aantal Java boeken lezen/herbeleven

Over verbindingen staat hierboven al wat. Dat gaat je niet zomaar lukken zonder dat je uit de sandbox springt. Wil je perse hier mee verder gaan, vergeet dan het hele webbased. Je kunt er niks mee en het bied geen enkele meerwaarde. Gewoon een clientside p2p applicatie ontwikkelen in wat voor taal dan ook is al lastig zat.

Zet het idee uit je hoofd. Zeker als dit je eerste java applicatie gaat worden neem je gewoon veel te veel hooi op je vork. Verzin een nieuw idee welke wel meerwaarde biedt en steek daar je energie in. Dat lijkt mij iig een stuk nuttiger en vruchtbaarder.

[RedHat]

In essentie snap je (hopelijk) wel wat ik bedoel De simpelheid in functies reffereer jij aan de simpelheid in code. Dat slaat natuurlijk nergens op. Dat het niet simpel is dat snap ik; maar simpel in gebruik, weinig functies, in essentie alleen de core 'toepassing' dat is wat ik gezegd heb.

Als ik zeg dat simpelheid de keyword is en jij reageerd met dat het niet simpel is; dan lees je mijn tekst verkeerd. Een simpele interface met 'simpele' features (zoals; geen resuming etc) wil nog niet zeggen dat de code dan ook maar simpel is

Buiten dat alles toch nog bedankt voor je comments. Je leest alleen mijn post totaal verkeerd en slaat dan op sommige punten ook volledig de plank mis. Iets als Omegle kan héél simpel van de buitenkant zijn maar hoeft niet simpel te zijn kwa code; dat is ook iets wat ik niet suggereer. Het moet een simpele opzet zijn met main functies. Dat die main functies niet simpel zijn is iets heel anders

Ik ben er ondertussen wel uit dat je beter een client kan maken dan iets webbased te maken. In ieder geval bedankt voor je reactie.

[Janoz]

Zou jij mij aan kunnen wijzen op welke punten ik de plank compleet mis sla? Ik zie namelijk niet op wat voor manier je post een reactie is op mijn verhaal. Daarnaast heb je nog steeds geen antwoord gegeven op de prangende vraag:

"Welk probleem ben je aan het oplossen?"

Zoals het nu lijkt (of leek, aangezien je het webbased hebt laten schieten) is het alleen alsof je twee buzzwords wilt combineren. Dat werkt heel leuk wanneer je het in een zin samenvoegt. Het probleem is echter dat er hier mensen rondlopen voor wie 'webbased' en 'peer 2 peer' meer zijn dan buzzwords. Iedereen is dan ook zeer benieuwd wat je nu daadwerkelijk wilt proberen en vraagt daarna.

Vanuit een technisch perspectief zijn deze dingen namelijk niet verenigbaar. Webbased komt technisch namelijk neer op 'Op een server geïmplementeerde functionaliteit die een sandboxed view op een client toont' terwijl peer2peer juist meer neerkomt op 'distributie van data waarbij de afhankelijkheid van een centrale server tot een minimum beperkt wordt'. Het is vervolgens geen rocketscience om in te zien dat beide termen zo goed als niet verenigbaar zijn. Het is dan ook een beetje flauw om iedereen die terecht vraagtekens bij je idee zet maar te beschuldigen van onbegrip.

[HaTe]

Heb je al naar Google Gears gekeken?

[RedHat]

Ja, ben nog steeds aan't kijken naar Google Gears. Maandag ga ik daar in ieder geval verder mee aan de slag.

Janoz: Mijn prangende vraag was dus of dit volledig webbased kon. Zoals ik al meerdere malen in dit topic heb vermeld. Maar ik zal nogmaals even het hele verhaal beknopt neerzetten voor je.

• Ik zat te denken aan een P2P client, volledig webbased, zoals napster.
• Heb hierop verschillende zaken gecheckt
• De techniek erachter; Vooral met ActiveX kom je een eind; dit is echter browserafhankelijk
• Daarna dacht ik; ik open een topic op GoT... Misschien hebben mensen wel technieken waar ik geen weet van weet. Misschien kunnen die mij andere inzichten kunnen laten inzien.
• Vervolgens wordt er gewezen naar Java&Flash
• Aangezien dit niet volledig webbased is, en er geen voordeel uitgehaald kan worden tussen webbased en software, heb ik gezegd dat dit misschien nog niet haalbaar is.

Ik ga dan ook even wat stukjes quoten.

Het punt is dat je hele idee gewoon niet klopt. Je start met het idee om p2p webbased te doen, maar zult langzaam tot de conclusie komen dat het enige waar je mee bezig bent gewoon een client applicatie maken. Daarbij zul je dezelfde problemen tegenkomen die losstaande applicaties ook hebben zoals firewalls en clients in een NAT omgeving. Daar bovenop introduceer je ook nog eens wat extra moeilijkheden doordat je je clients in een sandbox omgeving wilt laten draaien (want in de browser) waardoor je standaard geen toegang hebt tot het file systeem, niet de mogelijkheid krijgt om te verbinden met een andere client en al helemaal geen serversocket kunt openen om de aanvraag van een andere client te kunnen ontvangen.

Dit was dus de hele essentie van dit topic. Daarom zou webbased met een plugin-installatie uitkomst bieden. Concreet was de vraag dan ook of dit mogelijk is. Zoals andere GoTers al vermeldde, dat dit nauwelijks mogelijk is omdat je te kampen hebt met meerdere browsers. Vervolgens wordt er dus dit stukje weer geplaatst. Nu heb je me: Ik ga op mijn knieën. Ja, dit is niet mogelijk zoals je hierboven schetst. Wil je mij vergeven? Uitermate stomme vraag, en de kans dat deze technologiën met b.v. een multibrowser-plugin is natuurlijk van de zotte. Het spijt mij dan ook enorm.

De essentie van p2p is dat clients zelf onderling hun data uitwisselen. Het is inderdaad zo dat de servers over het algemeen als enige functie hebben om de clients van elkaars bestaan te laten weten.

Ja, dat is ook de essentie. Dat was de bedoeling. De server zal dus één en ander moeten initieren. Logisch toch? Ik wil wel eens een P2P protocol weten die niet volgens dit principe werkt. En als je iets 'webbased' zou willen initiëren is dit de enige mogelijkhied. Dan zou je mbv PHP prima de calls kunnen afhandelen. Dit stuk lijkt mij dan ook meer dan duidelijk

Er is een reden waarom dit met een applet eigenlijk nog niet gedaan is (Wel met een applicatie. Limewire en Azeurus zijn voorbeelden van p2p clients geschreven in java)

Ja... Op zich een toevoeging maar zonder onderbouwing. Er is ook een reden dat mensen in God geloven. Is leuk; maar zegt helemaal niets.

Wat is er uberhaupt nog webbased aan het protocol wanneer clients onderling een socket op gaan zetten? Of was je van plan om een webserver te gaan integreren in je java applets?

Wat er webbased aan is? Je start je browser, opent een webpagina, je start op die webpagina je P2P cliënt en shared daarvanuit je files. De verbinding wordt zelf P2P opgezet; maar daar heeft een gebruiker weinig mee te maken (als alles naar behoren werkt). Mja, ik snap je vraag dan ook niet helemaal? Waarom een webserver intregeren in een java-applet Je zal het wel anders bedoelen maar dit snap ik niet.

Je vraagt nu aan mij waar je de plank kompleet mis slaat. Ik quote een stukje van je:

Laat dat simpel maar weg. Wat jij probeert te doen is een redelijk ingewikkeld probleem oplossen (het schrijven van een p2p client) waarbij je vervolgens nog eens een enorme bak extra beperkingen toevoegt zonder dat dit ook maar 1 voordeel oplevert. Sterker nog, het wordt eerder gebruikers onvriendelijker.

Nu quote ik mezelf hieronder waarin ik daarvoor uitgelegd heb dat ik een zo simpel mogelijk systeem wil; geen resumeable downloads, simpele GUI, basisfunctionaliteit.

Erg leuk project waar ik mij in ga verdiepen. De simpelheid is de keyword. Less=More. Ik ga mij in ieder geval nog meer diepen in de materie.

Nu doel jij op heel wat anders. Jij gaat ineens inhoudelijk over code praten; dat de code niet simpel is. Dat bedoelde ik niet. Je sloeg dus compleet de plank mis met je reactie. Je reageerde op iets waar het op de eerste plek niet over ging. Dat het 'codingverhaal' niet simpel wordt dat had ik natuurlijk zelf wel begrepen. Daar ging het dan ook niet over.

Over verbindingen staat hierboven al wat. Dat gaat je niet zomaar lukken zonder dat je uit de sandbox springt. Wil je perse hier mee verder gaan, vergeet dan het hele webbased. Je kunt er niks mee en het bied geen enkele meerwaarde. Gewoon een clientside p2p applicatie ontwikkelen in wat voor taal dan ook is al lastig zat.

Dat een p2p applicatie ontwikkelen in wat voor taal dan ook lastig zat is dat begrijp ik. Maar dat steeds meer applicaties hun weg vinden in het webbased gebeuren is een feit. Waarom dan niet verder kijken? Waarom niet eens gaan onderzoeken of het ontwikkelen van een P2P Cliënt volledig webbased (buiten wat plugins om) niet haalbaar is. Dat zijn juist leuke ontwikkelingen. Stel dat het lukt; dan heb je een leuk iets! Vroeger hadden we ook niet verwacht dat je webbased kon emailen. Nu kan het wel. Zeg je over webbased email ook maar "Man, je moet gewoon een client installeren, emailen is al moeilijk genoeg". Dat is juist verder kijken; innovatie... Tot hoever rijkt de techniek, niets vreemds.

"Welk probleem ben je aan het oplossen?"

Het probleemveld is de techniek. Hoe ga je iets realiseren; welke technieken zijn daar het beste geschikt voor. Wat is uiteindelijk het beste voor de eindgebruiker, wat zijn de restricties, is het überhaubt mogelijk. Dat probleem wou ik met dit topic oplossen. Zoals ook te lezen is in de topicstart.

Ik zal nogeens de eerste en laatste alinea quoten voor je; dan is meteen duidelijk wat mijn vraagstelling is.

Ik wil een idee uitwerken op kleinschalige basis. Ik wil een Peer-to-peer programma maken, dit geheel webbased Nu zijn er natuurlijk een hoop limitaties. De grootste is: hoe access je de files. Hiervoor is denk ik een browserplugin nodig die de brug vormt tussen de gui/php > files.

Het gaat er dus om dat mensen een folder kan 'sharen'. Die folder moet doorgegeven worden aan PHP. Op het moment dat iemand anders de file aanklikt dan moet je dus bij de tegenpartij de file downloaden. Het idee lijkt me duidelijk. Ik hoef absoluut geen kant en klare oplossingen, het is meer de vraag of dit überhaubt kan en in welke richting ik moet gaan zoeken.

Duidelijk toch

Nu kom je in je laatste reply met dit:

Vanuit een technisch perspectief zijn deze dingen namelijk niet verenigbaar. Webbased komt technisch namelijk neer op 'Op een server geïmplementeerde functionaliteit die een sandboxed view op een client toont' terwijl peer2peer juist meer neerkomt op 'distributie van data waarbij de afhankelijkheid van een centrale server tot een minimum beperkt wordt'. Het is vervolgens geen rocketscience om in te zien dat beide termen zo goed als niet verenigbaar zijn. Het is dan ook een beetje flauw om iedereen die terecht vraagtekens bij je idee zet maar te beschuldigen van onbegrip.

Met plugins is files accessen wel mogelijk. De vraag is; hoe ga je dat bereiken en waarmee. Kijk eens naar HouseCall, die kunnen je harde schijf op virussen scannen, webbased. Toch niet zo'n gekke vraag van mij toch? Dat het op dit moment vaak alleen in commerciele toepassingen gebruikt wordt wil nog niet zeggen dat het niet verenigbaar zou zijn. Het is wel verenigbaar en zou prima moeten kunnen. De vraag is alleen, vooral in zin van usability, waar moet je stoppen; is dit wel handig.

Het is dan ook een beetje flauw om iedereen die terecht vraagtekens bij je idee zet maar te beschuldigen van onbegrip.

Ik beschuldig niemand van onbegrip. Dit is overigens een aanname van jouw kant. Ik vind alle reacties juist zeer zinvol. Mits het natuurlijk om de essentie van dit topic gaat.

[RayNbow]

RedHat schreef op donderdag 24 september 2009 @ 20:19:
Ja, dat is ook de essentie. Dat was de bedoeling. De server zal dus één en ander moeten initieren. Logisch toch? Ik wil wel eens een P2P protocol weten die niet volgens dit principe werkt.

Een P2P protocol.

[Verwijderd]

Adobe Air (webbased apps), werkt op elk platform.

[RedHat]

RayNbow schreef op donderdag 24 september 2009 @ 20:43:
[...]

Een P2P protocol.

Protocol was het verkeerde woord Maar goed; alle programma's zoals Kazaa werkten via een methode via een server.

[Gerco]

Zoek je misschien iets als Java Web Start? Daarmee kun je een website maken waar je via een linkje met 1 klik een programma kan opstarten wat lokale rechten kan krijgen (ok, dan moet je nog een keer klikken). Met Java6 kun je tegenwoordig ook een Applet maken volgens het web start principe:

Je start de applet op een web pagina, deze draait lokaal als een proces los van de webbrowser maar de gebruiker ziet dat niet (UI zit in de webpagina). De gebruiker kan vervolgens de applet *uit* de browser slepen en op de desktop zetten en ermee verder werken alsof er niets is veranderd. Zelfs nadat ze de browser afsluiten.

Belangrijk besef wat je moet hebben is dat je dus een *applicatie* aan het maken bent die je *opstart* vanaf het web, zonder lokale installatie. Dat is iets heel anders als "Web Based".

[edit]
Wat demos hier

[ Voor 5% gewijzigd door Gerco op 24-09-2009 21:09 ]

[RedHat]

Gerco schreef op donderdag 24 september 2009 @ 21:06:
Zoek je misschien iets als Java Web Start? Daarmee kun je een website maken waar je via een linkje met 1 klik een programma kan opstarten wat lokale rechten kan krijgen (ok, dan moet je nog een keer klikken). Met Java6 kun je tegenwoordig ook een Applet maken volgens het web start principe:

Je start de applet op een web pagina, deze draait lokaal als een proces los van de webbrowser maar de gebruiker ziet dat niet (UI zit in de webpagina). De gebruiker kan vervolgens de applet *uit* de browser slepen en op de desktop zetten en ermee verder werken alsof er niets is veranderd. Zelfs nadat ze de browser afsluiten.

Belangrijk besef wat je moet hebben is dat je dus een *applicatie* aan het maken bent die je *opstart* vanaf het web, zonder lokale installatie. Dat is iets heel anders als "Web Based".

[edit]
Wat demos hier

Dat klopt helemaal ja Het was puur om te kijken wat de mogelijkheden waren. In ieder geval bedankt voor je bijdrage.

[RayNbow]

RedHat schreef op donderdag 24 september 2009 @ 20:52:
[...]

Protocol was het verkeerde woord Maar goed; alle programma's zoals Kazaa werkten via een methode via een server.

Dan mag je toch eens uitleggen wat jij verstaat onder "zoals". Waaraan moet een programma voldoen om "zoals Kazaa (FastTrack)" te zijn?

[Janoz]

Redhat, jij hebt het over

bestanden te kunnen 'sharen' via een webbased protocol.

Ik geef enkel aan dat een p2p implementatie niet gaat werken met webbased protocollen en dat dit alleen echt goed lukt met een clientside applicatie. Dat die clientside applicatie vervolgens middels webstart gestart wordt maakt het imho niet ineens webbased.

[RedHat]

Janoz schreef op donderdag 24 september 2009 @ 21:36:
Redhat, jij hebt het over

[...]


Ik geef enkel aan dat een p2p implementatie niet gaat werken met webbased protocollen en dat dit alleen echt goed lukt met een clientside applicatie. Dat die clientside applicatie vervolgens middels webstart gestart wordt maakt het imho niet ineens webbased.

Daar heb je helemaal gelijk in. Denk toch echt dat we elkaar verkeerd begrijp(t)en.

[Janoz]

begr(ij | e)pen

[Voutloos]

RedHat schreef op donderdag 24 september 2009 @ 20:19:
Zoals andere GoTers al vermeldde, dat dit nauwelijks mogelijk is omdat je te kampen hebt met meerdere browsers.

Dat is niet het grootste probleem. (zie onder. )

De verbinding wordt zelf P2P opgezet; maar daar heeft een gebruiker weinig mee te maken (als alles naar behoren werkt). Mja, ik snap je vraag dan ook niet helemaal? Waarom een webserver intregeren in een java-applet

Hoe zet je zo'n verbinding op? Door uit het ene proces een ander proces te benaderen. Maar daarmee zeg je dus dat elk proces zo benaderd kan worden en dus in feite ook een server is. Dát is het grote probleem. Standaard speelt (gelukkig niet !) geen enkele browser een dergelijke rol en bovendien is dit de reden dat je toch altijd 'firewall gezeik' tegen gaat komen en het niet zomaar altijd zonder tussenkomst kan werken.

En nofi, maar als je zelf niet deze gedachtengang had, heb je het nodige leeswerk te doen voordat je code gaat kloppen van een p2p app in wat voor vorm dan ook.

[ Voor 8% gewijzigd door Voutloos op 24-09-2009 22:25 ]