[PHP] Verbinding openhouden zonder pagina te laden.

[Verwijderd]

Hallo tweakers,

Na mijn vorige topic over de socket_create, heb ik nu een andere vraag.
Hoe is het mogelijk om een verbinding open te houden zonder dat de pagina visueel word vernieuwd?
eBuddy bijvoorbeeld. Die zie je niet de heletijd laden. Als ik zo'n soortgelijk iets wil maken voor mn gameserver aan te sturen zie je de hele tijd dat laadbalkje bewegen.

[MueR]

eBuddy en dergelijke werken dan ook met asynchrone requests. HTTP is niet gemaakt om altijd open te staan

[Verwijderd]

MueR schreef op vrijdag 13 augustus 2010 @ 12:06:
eBuddy en dergelijke werken dan ook met asynchrone requests. HTTP is niet gemaakt om altijd open te staan

En heb je voor die asynchrone requests een aparte server nodig? Want ik ben zelf wel geïnteresseerd in die techniek.

Is dat javascript dan? want als ik google, 1ehit krijg ik dit

http://www.ibm.com/develo.../wa-ajaxintro2/index.html
AJAX (A)

[Manuel]

Ik neem aan dat je iets als AJAX Push (Comet) bedoelt? eBuddy werkt ook met AJAX Push, anders kunnen ze de berichten nooit real-time doorgeven.

Voor dit 'gebeuren' ga je een eigen server nodig hebben, omdat in 9/10 (of zelfs 10/10) gevallen de hoster het niet toestaat. Voor demo's van AJAX Push neem eens een kijkje op: APE Project

[CH4OS]

AJAX push heb je toch niet per sé nodig? Het is maar net wat je wil gaan doen. Ook met een gewone AJAX request kun je bijvoorbeeld iemand laten inloggen (ik zeg even iets) of een record uit een tabel in een database verwijderen...

[Manuel]

CptChaos schreef op vrijdag 13 augustus 2010 @ 13:59:
AJAX push heb je toch niet per sé nodig? Het is maar net wat je wil gaan doen. Ook met een gewone AJAX request kun je bijvoorbeeld iemand laten inloggen (ik zeg even iets) of een record uit een tabel in een database verwijderen...

Klopt, maar aangezien hij eBuddy als voorbeeld nam dacht ik dat hij dus AJAX Push bedoelde.

[bstudio]

Hier kun je toch gewoon Long Polling gebruiken, gewoon een XHR request doen en op de serverside gewoon laten wachten totdat er (bijvoorbeeld) een nieuw bericht uit de database oid komt.

Dit is met meerdere requests natuurlijk niet heel erg gezond voor je server.

[TheNephilim]

Manuel schreef op vrijdag 13 augustus 2010 @ 12:41:
Ik neem aan dat je iets als AJAX Push (Comet) bedoelt? eBuddy werkt ook met AJAX Push, anders kunnen ze de berichten nooit real-time doorgeven.

Voor dit 'gebeuren' ga je een eigen server nodig hebben, omdat in 9/10 (of zelfs 10/10) gevallen de hoster het niet toestaat. Voor demo's van AJAX Push neem eens een kijkje op: APE Project

Zeer intressant! Bedankt voor deze tip, kan ik misschien gebruiken in mijn nieuwste project

[DexterDee]

bstudio schreef op vrijdag 13 augustus 2010 @ 14:22:
Hier kun je toch gewoon Long Polling gebruiken, gewoon een XHR request doen en op de serverside gewoon laten wachten totdat er (bijvoorbeeld) een nieuw bericht uit de database oid komt.

Long Polling == Ajax Push == COMET

[.oisyn]

HTML 5 komt met web sockets, maar dat werkt momenteel alleen nog in maar in Safari en Chrome.
Voorbeeld

[ Voor 21% gewijzigd door .oisyn op 13-08-2010 17:50 ]

[dragontje124]

.oisyn schreef op vrijdag 13 augustus 2010 @ 17:49:
HTML 5 komt met web sockets, maar dat werkt momenteel alleen nog in maar in Safari en Chrome.

en in Chrome ook alleen maar als je 'm bij het opstarten een bepaalde flag meegeeft volgens mij.
daarnaast moet je voor web sockets ook een speciale app draaien op je server (web sockets ondersteunen dus geen normale sockets om misbruik te voorkomen)

[.oisyn]

Nee hoor, bovenstaand voorbeeld werkt bij mij gewoon met de normale versie zonder opstartparameters

[dragontje124]

.oisyn schreef op vrijdag 13 augustus 2010 @ 17:52:
Nee hoor, bovenstaand voorbeeld werkt bij mij gewoon met de normale versie zonder opstartparameters

ah true, dan was dat bij een oudere dev versie zo

[FragFrog]

.oisyn schreef op vrijdag 13 augustus 2010 @ 17:49:
HTML 5 komt met web sockets, maar dat werkt momenteel alleen nog in maar in Safari en Chrome.
Voorbeeld

Erm, niet helemaal correct.

Chrome's dev builds ondersteunen de laatste revisie van de websocket specificatie. Mozilla's nightly builds, ergo minefield, doen het sinds een paar weken ook. Safari loopt nog achter en gebruikt de oude specificatie. IE8 ondersteunt nog helemaal niks, Opera voor zover ik heb kunnen uitvogelen ook niet en IE9 heb ik hier nog niet kunnen testen - maar aangezien de specificatie nog in ontwikkeling is ga ik er niet vanuit.

Voor een hobby project ben ik bezig geweest met een websocket server in JAVA, vrij eenvoudig op te zetten maar je moet er even op letten dat beide versies van het protocol niet zomaar interchangeable zijn. Al zijn er al wel servers die beide ondersteunen (mijn implementatie niet overigens, 't is maar een hobby project, dan ga ik geen backwards compatibility inbouwen voor een spec die nog niet eens af is).

Ik ga er overigens vanuit dat het nog zeker wel een jaar duurt voor een respectabel deel van de gebruikte webbrowsers websockets ondersteunt. Als je wilt experimenteren is het gaaf en leuk, als je daadwerkelijk iets wilt bouwen wat werkt zou ik fijn voor een flash / COMET oplossing gaan

[ Voor 7% gewijzigd door FragFrog op 13-08-2010 21:15 ]

[Verwijderd]

Over dat comet, ik zie in veel voorbeelden dat ze gebruik maken van een iframe. Persoonlijk vind ik het gebruik van iframe's helemaal niks. Ik heb een voorbeeld http://www.zeitoun.net/articles/comet_and_php/start daar heb je een chat voorbeeld. Maar als er een update is word het script weer ge-herstart. Maar als ik verbinding heb met mn gameserver wil ik graag dat de verbinding NIET opnieuw word gestart.

[Manuel]

Jij hoeft niet wakker te liggen van het gebruik van iframe's, daar is namelijk helemaal niets mis mee in dit geval. Als je nou je site (links een blokje, rechts een blokje en een leuke footer) dat nou in een iframe zou zetten, dan ben ik het volkomen met je eens. Maar in dit geval om JavaScript te laden en zo een connectie tot stand brengen is wat overdreven, vindt je niet?

Om het even duidelijker te maken heeft Weelya (het team achter APE) wat illustraties gemaakt zodat het wat duidelijker wordt. Die illustraties zijn hier te vinden: http://www.ape-project.org/ajax-push.html

[Verwijderd]

Manuel schreef op vrijdag 13 augustus 2010 @ 22:31:
Jij hoeft niet wakker te liggen van het gebruik van iframe's, daar is namelijk helemaal niets mis mee in dit geval. Als je nou je site (links een blokje, rechts een blokje en een leuke footer) dat nou in een iframe zou zetten, dan ben ik het volkomen met je eens. Maar in dit geval om JavaScript te laden en zo een connectie tot stand brengen is wat overdreven, vindt je niet?

Om het even duidelijker te maken heeft Weelya (het team achter APE) wat illustraties gemaakt zodat het wat duidelijker wordt. Die illustraties zijn hier te vinden: http://www.ape-project.org/ajax-push.html

Oke! dus als ik het goed begrijp moet het ongeveer zo gaan werken (dit is niet voor mn gameserver btw, maar een webmessenger) http://dev.kevinvdburgt.n...senger%20Protocol%20Test/

[Freeaqingme]

Manuel schreef op vrijdag 13 augustus 2010 @ 12:41:
Voor dit 'gebeuren' ga je een eigen server nodig hebben, omdat in 9/10 (of zelfs 10/10) gevallen de hoster het niet toestaat. Voor demo's van AJAX Push neem eens een kijkje op: APE Project

Nouja, ik zou het in ieder geval wel even met je host bespreken. Ik lever zelf ook kwaliteits (doh ) shared webhosting, en wij zouden hier geen probleem mee hebben, mits het niet onevenredig zwaar ons platform belast (ten opzichte van het soort pakket/SLA dat ze hebben). Het lijkt me dat wij daarmee niet de enige zijn.

offtopic:
Gezien vanaf got mijn nick niet echt tot een bedrijsnaam leidt lijkt me dit geen spam

[Manuel]

freakingme schreef op zaterdag 14 augustus 2010 @ 00:29:
[...]


Nouja, ik zou het in ieder geval wel even met je host bespreken. Ik lever zelf ook kwaliteits (doh ) shared webhosting, en wij zouden hier geen probleem mee hebben, mits het niet onevenredig zwaar ons platform belast (ten opzichte van het soort pakket/SLA dat ze hebben). Het lijkt me dat wij daarmee niet de enige zijn.

offtopic:
Gezien vanaf got mijn nick niet echt tot een bedrijsnaam leidt lijkt me dit geen spam

Hier heb ik toen die tijd ook een gesprek met mijn hoster over gehad en de belangrijkste reden was dat hij niet kon controleren wat de daemon allemaal aan het uitspoken was. Sommige programma's hebben nog wel eens last van een aantal memory leaks, dus daar komt ook weer allemaal extra werk bij te kijken.

Op het laatst ben ik het dus met hem eens geworden dat het voor mij makkelijker en leerzamer was om eerst maar een virtuele machine aan te maken op je eigen computer en dat je op die manier leert dat het toch allemaal net niet zo makkelijk is als dat de tools je doen laten denken. (Kijk maar eens naar DirectAdmin, het ziet er allemaal erg simpel uit, maar onder de kap is het net wat uitgebreider)

Wat ik bedoel te zeggen, pas op met wat je zegt.

Verwijderd schreef op vrijdag 13 augustus 2010 @ 22:51:
[...]

Oke! dus als ik het goed begrijp moet het ongeveer zo gaan werken (dit is niet voor mn gameserver btw, maar een webmessenger) http://dev.kevinvdburgt.n...senger%20Protocol%20Test/

Dit is een eenmalige request naar de server toe, die haalt dus de inhoud op voor de status van hoe die op dat moment is, het wordt dus niet geüpdatet, indien je AJAX Push gebruikt is dat wel het geval. Om nog maar eens een simpel voorbeeldje te geven: APE - Color Changer

[Sgreehder]

Ik gebruikte deze nog al eens:

http://api.prototypejs.org/ajax/ajax/periodicalupdater/

Deze heeft ook een mechanisme om het pollen steeds wat langer te laten duren, de load op de server wordt dus kleiner naarmate de tijd verstrijkt.

[Verwijderd]

Het is intussen gelukt om een bestand aan te roepen. met Ajax. alleen krijg ik het resultaat pas te zien wanneer de pagina klaar is met laden. En ja ik heb flush(); gebruikt. Komt het omdat de AjaxReqeust eerst alles moet hebben voordat je de responseText krijgt?

[.oisyn]

FragFrog schreef op vrijdag 13 augustus 2010 @ 21:13:
[...]

Erm, niet helemaal correct.

Chrome's dev builds ondersteunen de laatste revisie van de websocket specificatie.

Onzin, ik zit in de stable channel en daarin werkt het gewoon (5.0.375.126). Verder ging ik gewoon uit van wat http://html5demos.com/ aangaf.

[ Voor 12% gewijzigd door .oisyn op 16-08-2010 13:17 ]

[FragFrog]

.oisyn schreef op maandag 16 augustus 2010 @ 13:11:
Onzin, ik zit in de stable channel en daarin werkt het gewoon (5.0.375.126). Verder ging ik gewoon uit van wat http://html5demos.com/ aangaf.

Dat de dev builds de laatste revisie van de websocket specificatie implementeren betekend nog niet dat eerdere builds niet een revisie aankunnen - lezen gaarne. Chrome 5.x implementeert revisie 75, alleen Chrome 6.x en Minefield ondersteunen de laatste revisie en die twee zijn niet zonder meer backwards compatible - handshake is dusdanig aangepast dat je zonder speciale uitzondering serverside geen oude clients kan bedienen. Dat is toch wel iets om rekening mee te houden, als je nu een server bakt die de 75-draft implementeert (wat Chrome 5.x of Safari bijvoorbeeld gebruiken) kun je daar over een paar maanden niks meer mee.

[.oisyn]

Zeg dat dan!

[Verwijderd]

Ik heb het volgende ook al geprobeerd. (zie link)
http://dev.kevinvdburgt.nl/test/PHP COMET/Test 001/

Maar dan word er een script geladen. Ik kan niks aanroepen op de server totdat het script klaar is. Het werkt wel, maar niet zoals het moet.

Want ik kan ook niet 2 clients tegelijkertijd dat script laten laden.