[PHP] Direct data doorgeven

[sandr]

Dit is wat ik wil:
Gebruiker 1 stuurt een bericht naar pagina A, die zorgt ervoor dat pagina B een update verstuurd naar gebruiker 2. Dit lukt al redelijk, alleen heb ik nu dat pagina B met een while loop constant gaat checken of er een update is. In deze while loop zit natuurlijk wel een sleep() om te voorkomen dat de cpu naar 100% vliegt, maar het probleem is dat hoe hoger ik deze sleep instel hoe trager de update verloopt. Dus ik zoek eigenlijk een manier om die update direct te lagen gaan.

Ik heb al wat geprobeerd met linux commands die sleep() kunnen stoppen, maar dit werkt niet op alle servers, wat eigenlijk wel zo handig is.

[Haan]

Wat misschien mooier is, is je pagina B vervangen door een webservice. Die kan dan aangeroepen worden door A en op dat moment dingen naar gebruiker 2 doorsturen.

[DJF5]

Je kunt met ajax wel mooie dingen maken...

Hoe google dat doet in Wave is in iedergeval met XMPP

[Voutloos]

DJF5 schreef op zaterdag 10 oktober 2009 @ 13:58:
Je kunt met ajax wel mooie dingen maken...

Zal best, maar deze algemene uitspraak heeft verder weinig met het topic te maken. Tenzij je je briljante manier om data te pushen uit de doeken doet.

[sandr]

Haan schreef op zaterdag 10 oktober 2009 @ 13:51:
Wat misschien mooier is, is je pagina B vervangen door een webservice. Die kan dan aangeroepen worden door A en op dat moment dingen naar gebruiker 2 doorsturen.

Zou kunnen, ben zelf niet zo thuis in webservice's, maar kan me er eens in verdiepen.

DJF5 schreef op zaterdag 10 oktober 2009 @ 13:58:
Je kunt met ajax wel mooie dingen maken...

Hoe google dat doet in Wave is in iedergeval met XMPP

AJAX zal hier niet werken, want dan zit je nog steeds met een constante while loop wat er behoorlijk wat dataverkeer doorheenjaagt.

[Verwijderd]

Voutloos schreef op zaterdag 10 oktober 2009 @ 14:01:
[...]
Zal best, maar deze algemene uitspraak heeft verder weinig met het topic te maken. Tenzij je je briljante manier om data te pushen uit de doeken doet.

http://www.ape-project.org/

[frickY]

Waarom wil je hier perse PHP voor gebruiken? Een client-side taal is hier veel beter voor geschikt.
Pak een javascript of Flashobject die de server polled voor nieuwe berichten.

Pushen gaat sowieso niet, HTTP is stateless.Dan moet je bijv. het IRC protocol gaan pakken.

[sandr]

frickY schreef op zaterdag 10 oktober 2009 @ 14:17:
Waarom wil je hier perse PHP voor gebruiken? Een client-side taal is hier veel beter voor geschikt.
Pak een javascript of Flashobject die de server polled voor nieuwe berichten.

Pushen gaat sowieso niet, HTTP is stateless.Dan moet je bijv. het IRC protocol gaan pakken.

Ik gebruik PHP omdat alles wat verstuurd wordt ook nog in een database moet worden opgeslagen, daarnaast vraag ik me af hoe je met alleen javascript data van gebruiker A naar B laat versturen.

Verwijderd schreef op zaterdag 10 oktober 2009 @ 14:13:
[...]

http://www.ape-project.org/

Ziet er interessant uit.

[skabouter]

The APE Server keeps the connection open waiting for data ready to be sent to a user. Once data is available for a user, the server closes the current connection with this user to be able to read the data (this is due to AJAX specification paradigm). Then, the APE server send them to the user while re-opening a new permanent connection.

He dat is toch geen PUSH Bij Ape moeten ze maar eens goed bekijken wat PUSH inhoud:

Wkipedia:

Push services are often based on information preferences expressed in advance. This is called a publish/subscribe model. A client might "subscribe" to various information "channels". Whenever new content is available on one of those channels, the server would push that information out to the user.

[...] which means the sender initiates the data transfer rather than the recipient.

Bij APE laten ze gewoon de client elke x seconden vragen of er al wat nieuws is, dat is natuurlijk nog steeds geen PUSH!

[sandr]

skabouter schreef op zaterdag 10 oktober 2009 @ 15:39:
[...]


He dat is toch geen PUSH Bij Ape moeten ze maar eens goed bekijken wat PUSH inhoud:

Wkipedia:

[...]


Bij APE laten ze gewoon de client elke x seconden vragen of er al wat nieuws is, dat is natuurlijk nog steeds geen PUSH!

Dit valt volgens mij wel onder push, AJAX vraagt pagina aan, en die pagina geeft pas antwoord als er een update is, dus wordt die direct doorgegeven. Alleen als er binnen 30 sec geen update is wordt er gewoon een leeg antwoord gegeven om errors te voorkomen.

[Verwijderd]

sandr schreef op zaterdag 10 oktober 2009 @ 16:16:
[...]

Dit valt volgens mij wel onder push, AJAX vraagt pagina aan, en die pagina geeft pas antwoord als er een update is, dus wordt die direct doorgegeven. Alleen als er binnen 30 sec geen update is wordt er gewoon een leeg antwoord gegeven om errors te voorkomen.

Niet helemaal.

Wikipedia: Push technology

Is "Long polling"?

Long polling is itself not a push technology, but can be used under circumstances where a real push is not possible.

[sandr]

Verwijderd schreef op zaterdag 10 oktober 2009 @ 16:37:
[...]

Niet helemaal.

Wikipedia: Push technology

Is "Long polling"?

[...]

Ow, dan niet, maar opzich lijkt Long polling me niet verkeerd aangezien het nauwelijks aan je recources vreet (Ok, wel minder dan echt push, maar niet veel) en je toch een snelle update hebt.

APE zal trouwens niet werken op windows, hier staat namelijk dat het alleen op linux werkt.

[Verwijderd]

nm

[ Voor 93% gewijzigd door Verwijderd op 10-10-2009 17:02 ]

[psychonetics]

Ik heb er niet heel veel verstand van, maar is het Observer pattern hier niet geschikt voor? (Of is dat wat jullie bedoelen met PUSH? )

[sandr]

psychonetics schreef op zaterdag 10 oktober 2009 @ 17:10:
Ik heb er niet heel veel verstand van, maar is het Observer pattern hier niet geschikt voor? (Of is dat wat jullie bedoelen met PUSH? )

Zoiets ja, alleen dan in PHP.

[ixi]

Als je enkele milliseconden wacht (met behulp van usleep) zal de cpu nog steeds erg laag blijven, en je response tijd nog steeds redelijk snel. Afhankelijk van waar je het voor wilt gebruiken lijkt me dit ruim voldoende. Als je 1000den users verwacht is het wellicht niet de beste methode, maar dan kun je ook beter niet voor PHP gaan lijkt me. Er zijn genoeg betere methodes te verzinnen, maar die zullen allemaal complexer zijn om te implementeren en als je het niet nodig hebt kun je de tijd beter ergens anders in steken.

Om je database te sparen zou je eventueel voor memcache kunnen gaan voor 'inter'-php communicatie (of sockets, wordt ook weer complex), hoewel een memory mysql-database voor de meeste toepassingen ook snel genoeg is.

[mithras]

sandr schreef op zaterdag 10 oktober 2009 @ 20:30:
[...]

Zoiets ja, alleen dan in PHP.

Tja, Zend_Message is een php implementatie van het observer pattern.

Jij wil dit eigenlijk niet echt in php, want met alleen serverside bereik je geen push (of long polling) techniek Want php is natuurlijk ook beperkt tot de lengte van het request Je zal sowieso ook naar client side oplossingen moeten gaan kijken. Dan is APE een goede oplossing. Ik hoor ook wat van Comet, maar weet niet of dat weer wat anders is of dat APE een implementatie van Comet is

[ Voor 5% gewijzigd door mithras op 10-10-2009 23:39 ]

[ixi]

Je kan ook met een (onzichtbare) Flash movie een connectie open gooien naar een simpele socketserver, waarbij de client zijn (PHP) session ID meegeeft zodat de socketserver weet wie hij is. Daarna kan een PHP script een verbinding maken naar die socketserver om zo een berichtje door te kaatsen naar de Flash movie bij de client. Dit zou gewoon javascript kunnen zijn, welke de Flash movie vervolgens kan uitvoeren. Beetje kort door de bocht allemaal, maar ik hoop dat het idee duidelijk is. Je moet dan alleen een socketserver kunnen programmeren. In Java is dat redelijk eenvoudig... Ik heb het zelfs een keer in PHP gemaakt, welke uiteraard niet door Apache werd gedraaid

[sandr]

ixi schreef op zaterdag 10 oktober 2009 @ 23:28:
Als je enkele milliseconden wacht (met behulp van usleep) zal de cpu nog steeds erg laag blijven, en je response tijd nog steeds redelijk snel. Afhankelijk van waar je het voor wilt gebruiken lijkt me dit ruim voldoende. Als je 1000den users verwacht is het wellicht niet de beste methode, maar dan kun je ook beter niet voor PHP gaan lijkt me. Er zijn genoeg betere methodes te verzinnen, maar die zullen allemaal complexer zijn om te implementeren en als je het niet nodig hebt kun je de tijd beter ergens anders in steken.

Om je database te sparen zou je eventueel voor memcache kunnen gaan voor 'inter'-php communicatie (of sockets, wordt ook weer complex), hoewel een memory mysql-database voor de meeste toepassingen ook snel genoeg is.

Ik gebruik nu usleep ja, opzich gaat de update wel snel genoeg, maar ik wil alleen de serverload zo laag mogelijk houden en ik vroeg me gewoon af of dit dus niet anders kan.

mithras schreef op zaterdag 10 oktober 2009 @ 23:38:
[...]
Tja, Zend_Message is een php implementatie van het observer pattern.

Jij wil dit eigenlijk niet echt in php, want met alleen serverside bereik je geen push (of long polling) techniek Want php is natuurlijk ook beperkt tot de lengte van het request Je zal sowieso ook naar client side oplossingen moeten gaan kijken. Dan is APE een goede oplossing. Ik hoor ook wat van Comet, maar weet niet of dat weer wat anders is of dat APE een implementatie van Comet is

Het hoeft ook niet alleen serversided te zijn, dus long polling kan heel goed, daarnaast is Comet meer een allesomvattende naam waar oa. long polling bij hoort.

[ Voor 27% gewijzigd door sandr op 11-10-2009 00:01 ]

[ixi]

Heb je cijfers van die serverload?

Met een 1 ms usleep zakte in mijn implementatie de load al naar minder dan 0.01%, wat voor mij voldoende was om het niet meer verder te gaan optimaliseren.

[sandr]

ixi schreef op zondag 11 oktober 2009 @ 00:06:
Heb je cijfers van die serverload?

Met een 1 ms usleep zakte in mijn implementatie de load al naar minder dan 0.01%, wat voor mij voldoende was om het niet meer verder te gaan optimaliseren.

Heb op het moment geen cijfers (heb de server ook niet zelf in beheer), maar opzich is 0,01% per gebruiker wel acceptabel.