[PHP/JS]Comet en php. Goede handleidingen

Ik heb in het verleden hier de vraag gesteld om socket 'gegevens' direct naar de browser van de gebruiker te sturen.

Iemand zei 'doe dat met AJAX (Pollen)'. IK heb dat gemaakt. In praktijk blijkt dat toch niet helemaal lekker te werken.
Ik wil eigenlijk direct de data vanaf de server bij 'alle' clientbrowsers hebben.

Nu tipte iemand mij op http push --> comet. Ik heb hier hard naar gaan zoeken op google en vind wel wat uitleg (plaatjes en voorbeeldcode). Alleen werken al deze voorbeelden met een js framework of zo iets.

Ik kan nergens een goede handleiding vinden over http push. Dus uitgelegd hoe het precies werkt (dus de js code en de server site code).

Weet iemand een goede handleiding (engels geen probleem ) of een boek waarin eigenlijk uitgelegd staat hoe http push werkt. Zodat ik het zelf kan maken/begrijpen

Al eens gewoon hier of hier gekeken?
Ik kan je overigens wel vast verklappen dat dit niet betrouwbaar gaat werken en dat je eens serieus moet overwegen of je a) wel de juiste technologie voor je probleem hebt gekozen en misschien beter een "winforms" (of andere vorm van) client applicatie had moeten maken of b) je model niet anders kan waardoor je push overbodig maakt. Wil je toch in je browseromgeving blijven dan is een Java applet (of Flash ding ofzo) waarschijnlijk de "betere" manier.
Hoe dan ook is het HTTP protocol in den beginne opgezet als "pull" protocol en dat proberen om te buigen naar "push" is niet eenvoudig laat staan betrouwbaar en een combinatie van die 2 is erg zeldzaam

RobIII wijzigde dit bericht 04-07-2008 09:28 (58%)

Dank je voor je linkjes
Dit programma werkt op een intranet omgeving dus de network problemen die aangedragen worden zijn te 'controleren'. Op een internet omgeving heb je 'last' van firewalls maar op de intranet omgeving is daar wel wat aan te doen.

Een applet zou misschien kunnen. Ma mijn voor keur gaat uit naar PHP/Javascript/AJAX omdat ik die talen al beheers. en java applets niet. Dus mocht het op te lossen zijn in de gewenste talen scheeld dat tijd

Dan vraag ik me af, gegeven een intranet omgeving*, waarom je AJAX polls niet (goed) werken. Als je dat al niet (goed) werkend krijgt dan vergeet de HTTP push maar helemaal. Heb je al onderzocht waarom je poll niet werkt?

En kun je wat meer vertellen over het probleem dat je probeert op te lossen? Het lijkt me dat je (near) realtime gegevens wil hebben op je clients, maar in een web-omgeving is dat zelden écht nodig (iig veel minder vaak dan je denkt ).

_{* waar je dus meestal een low latency verbinding hebt en dus kunt wegkomen met een wat hogere poll-interval als je daarmee de server niet te zwaar belast}

RobIII wijzigde dit bericht 04-07-2008 09:33 (23%)

Nou wat er gebeurde is dat de wijizgingen op de socket niet direct bij de client te zien zijn. Daar zit een delay tussen namelijk de poll time.
Ik wil dat voorkomen. En dus socket wijigingen direct zichtbaar maken bij de client.

http push is officieel niet mogelijk. Zodra de webserver de html naar de browser heeft gestuurd (response over dezelfde tcp verbinding als het request is gekomen), kan deze de browser daarna niet meer benaderen.

Onder andere Firefox accepteert het content-type 'multipart/x-mixed-replace' wat inhoud dat als dit content type wordt ontvangen door een XmlHttpRequest object, de verbinding niet wordt gesloten. De verbinding wordt dus opgehouden en door het sturen van additionele (multi)parts zijn server pushed events mogelijk. Echter houd je wel altijd een verbinding met de webserver open. Dat kan dus de performance op zeer negatieve wijze beinvloeden, wat ook de belangrijkste reden is dat de comet techniek bijna niet wordt gebruikt.

Een voorbeeld welke ik in mijn bookmarks heb staan is http://ajaxpatterns.org/HTTP_Streaming.

Oke. IK ga het eens proberen/testen.
Op zich is het logisch dat de verbinding tussen client/server weg is.
De stream open laten staan is een optie.

Ik kan ook een ajax script maken dat iets opvraagd bij de server en de server rerturnt standaard niks totdat er een wijziging op de socket plaatsvind. Maar dan heb je ook weer het probleem met de openverbinding.

Ik ga dat gewoon eens testen en bekijken wat de gevolgen zijn voor de peformance

quote:

Jochemmol schreef op vrijdag 04 juli 2008 @ 09:00:
socket 'gegevens' direct naar de browser van de gebruiker te sturen.

quote:

Jochemmol schreef op vrijdag 04 juli 2008 @ 09:35:
Nou wat er gebeurde is dat de wijizgingen op de socket niet direct bij de client te zien zijn. Daar zit een delay tussen namelijk de poll time.
Ik wil dat voorkomen. En dus socket wijigingen direct zichtbaar maken bij de client.

quote:

Jochemmol schreef op vrijdag 04 juli 2008 @ 09:43:
de server rerturnt standaard niks totdat er een wijziging op de socket plaatsvind

Je hebt het steeds over wijzigingen op de socket? Je hebt het over een andere socket dan die met de client is verbonden op het moment van de HTTP request neem ik aan? En again; hoe "real-time" wil je gaan? Moet het écht zo "real-time"? Een poll van een (paar) seconde(s) is teveel?? Echt? Echt echt? Vertel eens wat je nou eigenlijk aan 't doen bent?

RobIII wijzigde dit bericht 04-07-2008 09:56 (32%)

Daar heb je een goed punt.
Op de server draait een socket server op poort x (bv 1234).
Op deze socket kan een telefoontje binnen komen.
Als ik per zoveel seconde poll dan kan het zijn dat de beller aan de lijn wacht zonder dat de client door heeft dat hij gebeld wordt.

Ik wil dat de client direct de melding krijgt dat er gebeld wordt. daarom is het nodig dat de melding direct gepusht wordt.

quote:

Jochemmol schreef op vrijdag 04 juli 2008 @ 09:59:
Ik wil dat de client direct de melding krijgt dat er gebeld wordt. daarom is het nodig dat de melding direct gepusht wordt.

Dan vraag ik me af wat je in een browseromgeving doet?

quote:

Jochemmol schreef op vrijdag 04 juli 2008 @ 09:59:
Als ik per zoveel seconde poll dan kan het zijn dat de beller aan de lijn wacht zonder dat de client door heeft dat hij gebeld wordt.

Euh, die client belt met z'n browser? Ik neem aan dat z'n telefoon ook begint te rinkelen

offtopic:
Toevallig met asterisk bezig? Hebben we een heel mooi real-time ("winforms")componentje/wrappertje voor geschreven /spam (maar helaas is die niet te koop of open source /nospam )

RobIII wijzigde dit bericht 04-07-2008 10:08 (27%)

De software die ze gebruiken is webbased.
JA dat asterisk heb ik ook even naar gekeken.
Het nadeel is dat het programma php is. dat maakt het nu lastig

quote:

RobIII schreef op vrijdag 04 juli 2008 @ 10:04:
Euh, die client belt met z'n browser? Ik neem aan dat z'n telefoon ook begint te rinkelen

Ja die rinkeld ook. Maar het moet mogelijk zijn op te nemen via de software. daarnaast registreerd de software automatisch dat er gebeld is.

quote:

Jochemmol schreef op vrijdag 04 juli 2008 @ 10:12:
[...]

Ja die rinkeld ook. Maar het moet mogelijk zijn op te nemen via de software.

Maar dan is een poll van een seconde (of 2...) toch geen ramp; als je per-se wil opnemen met een muisklik dan komt 'ie dus zo wel in beeld en anders pak je gewoon de hoorn van de haak.

quote:

Jochemmol schreef op vrijdag 04 juli 2008 @ 10:12:
daarnaast registreerd de software automatisch dat er gebeld is.

Ik neem aan dat de server dat al lang gedaan heeft voordat er uberhaupt een telefoon gaat rinkelen? Wat heeft de client hier mee van doen?

En why, o why, is hier nou gekozen voor PHP dan Over jezelf in een hoekje schilderen gesproken

RobIII wijzigde dit bericht 04-07-2008 10:37 (3%)

quote:

RobIII schreef op vrijdag 04 juli 2008 @ 10:36:
[...]

Maar dan is een poll van een seconde (of 2...) toch geen ramp; als je per-se wil opnemen met een muisklik dan komt 'ie dus zo wel in beeld en anders pak je gewoon de hoorn van de haak.


[...]

Ik neem aan dat de server dat al lang gedaan heeft voordat er uberhaupt een telefoon gaat rinkelen? Wat heeft de client hier mee van doen?

En why, o why, is hier nou gekozen voor PHP dan Over jezelf in een hoekje schilderen gesproken

Dat er voor PHP gekozen is heb ik geen invloed opgehad. De server registreerd niet automatisch wie er heeft gebeld. Dat zou nog wel kunnen maar de server registreerd ook wie er opgenomen heeft en daarom is de client interactie belangrijk omdat er meerdere clienten de melding telefoon krijgen. Degenen die opneemt die klikt in zijn venster aan dat hij opneemt en alles wordt dan opgeslagen.

Dus de telefoon rinkelt, en dan moet degene die de telefoon aanneemt ook nog eens in de browser aangeven dat hij de telefoon opgepakt heeft? Is dat alleen voor registratiedoeleinden, of ook om inhoudelijke gegevens van dat telefoongesprek te registreren? Hoe dan ook, een browseromgeving lijkt me niet geschikt. Kun je het gedeelte voor de clients niet tot een normale applicatie bouwen?

Anyway, waarom niet Ajax met long polling? Je geeft dan een time-out van bijvoorbeeld 30 seconden. De server haalt bij elke request een wait handle (global event of ManualResetEvent uit de Application state in ASP.NET termen), en wacht met een time-out van 25 seconden op een event. Als de time-out verstrijkt dan zijn er geen wijzigingen, en dan doet de browser daarna exact dezelfde request. Als er een wijziging is, dan moet de applicatie die de wijziging doorvoerde op de server dat event setten. De wijzigingen worden dan direct naar de client gestuurd, omdat de verbinding openstaat en er gewacht wordt op dat event.

Geen idee hoe dit in PHP zou moeten, maar dit kun je vrij eenvoudig implementeren. Nadeel hiervan is dat elke client een thread op de server heeft. Er gebeurt welliswaar weinig in die thread (voornamelijk wachten), maar het kost wel resources. Dit zal in jouw intranet omgeving geen probleem zijn.

ja dat pollen met AJAX is zeker een oplossing.
Dus na elke x seconde de request aborten. en opnieuw starten.
Maar het is dus de vraag of dat 'goed' is. Het is zeker voor een internet omgeving niet goed maar op intranet zou het kunnen.

De eerste goede PHP/JS oplossing voor http push (comet) moet ik nog zien. Een hoop mensen claimen dat ze het hebben maar dan is het vaak : 1. toch polling of 2. een php script zonder timeout die met output buffering steeds stukjes 'streamt'. En dat laatste, dat wil je niet imo.

quote:

Jochemmol schreef op vrijdag 04 juli 2008 @ 15:04:
Maar het is dus de vraag of dat 'goed' is. Het is zeker voor een internet omgeving niet goed maar op intranet zou het kunnen.

Als je mijn persoonlijke mening vraagt: heel het push-principe wil je niet in je browser liggen frotten tenzij je met Java applets of dat soort zaken aan de slag gaat. Maar dat is maar mijn €0.02

Oke dan ga ik toch gewoon een AJAX script maken dat iedere 2 seconde polled
Ik denk dat dat het beste is.
Dat zal op mijn intranet omgeving geen probleem zijn.

quote:

Jochemmol schreef op vrijdag 04 juli 2008 @ 15:04:
ja dat pollen met AJAX is zeker een oplossing.
Dus na elke x seconde de request aborten. en opnieuw starten.
Maar het is dus de vraag of dat 'goed' is. Het is zeker voor een internet omgeving niet goed maar op intranet zou het kunnen.

Wat is "niet goed"? Het is net voor welk doel het dient. Er wordt niets afgebroken; de server wacht gewoon 25 seconden en stuurt dan een bericht naar de client dat er niets gewijzigd is. Dat gebeurt allemaal prima in 30 seconden (de time-out in de browser). Wat een probleem zou zijn is dat de browser niet meer op de response van de server wacht door een time-out, maar dat de server nog wel oneindig op een event wacht. In dat geval breekt de webserver die thread trouwens wel af. Maar zolang de time-out in de browser hoger is dan op de server, is er niks aan de hand en wordt niets hardhandig afgebroken.

Het meest ideale is op de server bepalen wat het gedrag is van de browser. Dus dat je telkens meegeeft wat de interval en time-out moet zijn op basis van belasting op de server. Stel dat je interval 4 seconden is en time-out 2 seconden, dan is de helft van de wijzigingen echt direct in beeld, de andere helft gemiddeld na één seconde terwijl het dus twee keer zo weinig threads kost. Maargoed, allemaal niet relevant voor een intranetomgeving.

quote:

RobIII schreef op vrijdag 04 juli 2008 @ 15:55:
[...]
Als je mijn persoonlijke mening vraagt: heel het push-principe wil je niet in je browser liggen frotten tenzij je met Java applets of dat soort zaken aan de slag gaat. Maar dat is maar mijn €0.02

Dat hangt er maar net vanaf waar je mee bezig bent. Goed, een browser dan wel het http protocol zijn niet gemaakt voor dit soort doeleinden. Echter, door lage vertraging en grote bandbreedte van internet tegenwoordig plus de verschuiving van normale applicaties naar web applicaties, vind ik het niet zo gek meer.

quote:

Jochemmol schreef op vrijdag 04 juli 2008 @ 16:08:
Oke dan ga ik toch gewoon een AJAX script maken dat iedere 2 seconde polled
Ik denk dat dat het beste is.
Dat zal op mijn intranet omgeving geen probleem zijn.

Eén seconde is ook geen enkel probleem in een intranet omgeving.