[PHP] Long polling server strategie

Pagina: 1
Acties:

Vraag


Acties:
  • 0 Henk 'm!

  • xilent_xage
  • Registratie: Februari 2005
  • Laatst online: 15-09 11:35
Hoi,

Ik weet dat er frameworks zijn die geschikter zijn, maar ik probeer een oplossing te bouwen in PHP die gebruik maakt van long polling. In de communicatie tussen client en server snap ik denk ik redelijk hoe de vork in de steel zit, maar aan de serverkant blijf ik zitten met de vraag hoe dit efficitent kan worden ingezet.

De meeste voorbeeldscripts werken met een while loop waarin een database of bestand wordt gecheckt op wijzigingen met daarna een sleep. Dat betekent nog steeds loeiveel overhead natuurlijk. Nou vroeg ik mij af of het mogelijk was om ook serverside wat slimmer te werken. Ik dacht taan de volgende opzet:

1. Een binnengekomen request bevat een json lijstje van variabelen die in de gaten moeten worden gehouden.
2. Het script dat de request behandelt doet niks anders dan deze variabelen ergens (db?) noteren en GEEN response sturen (kan dat netjes?).
3. Zodra er een variabele verandert en deze voorkomt in het lijstje uit stap 2 dan naar alle watchers handmatig een reply met de nieuwe waarde sturen.

Is dit inderdaad een slimmere opzet en is dit haalbaar? Is het mogelijk om geen reply te sturen op een request en vervolgens handmatig een reply te sturen naar alle andere clients uit een lijstje? Zoja hoe?

Alle reacties


Acties:
  • 0 Henk 'm!

  • Glewellyn
  • Registratie: Januari 2001
  • Laatst online: 29-09 13:57

Glewellyn

is er ook weer.

xilent_xage schreef op maandag 19 september 2022 @ 16:20:
1. Een binnengekomen request bevat een json lijstje van variabelen die in de gaten moeten worden gehouden.
2. Het script dat de request behandelt doet niks anders dan deze variabelen ergens (db?) noteren en GEEN response sturen (kan dat netjes?).
3. Zodra er een variabele verandert en deze voorkomt in het lijstje uit stap 2 dan naar alle watchers handmatig een reply met de nieuwe waarde sturen.
ad 2. Als je geen response stuurt hoe weet de client dan dat het request door de server ontvangen is en niet ergens in een zwart gat verdwenen is?

ad 3. Hoe detecteer je dat een variabele gewijzigd is?

*zucht*


Acties:
  • 0 Henk 'm!

  • xilent_xage
  • Registratie: Februari 2005
  • Laatst online: 15-09 11:35
Glewellyn schreef op maandag 19 september 2022 @ 16:26:
ad 2. Als je geen response stuurt hoe weet de client dan dat het request door de server ontvangen is en niet ergens in een zwart gat verdwenen is?
Sorrie ik was iets te kort door de bocht. Misschien moet ik wel een header terugsturen, maar geen content.
Glewellyn schreef op maandag 19 september 2022 @ 16:26:
ad 3. Hoe detecteer je dat een variabele gewijzigd is?
Variabelen worden gewijzigd middels een API call (script dus), dus in die call kan ik checken op watchers en responses gaan verzenden.

Acties:
  • +1 Henk 'm!

  • CodeCaster
  • Registratie: Juni 2003
  • Niet online

CodeCaster

Can I get uhm...

Definieer "efficiënt" en "loeiveel overhead". Er moet nou eenmaal een proces een socket openhouden zolang er data te versturen is. Het is namelijk nogal des PHP's om je ontzettend zorgen te maken of een int-parse sneller wordt afgehandeld dan een null-check, om vervolgens twee regels verder een hele databasetabel leeg te trekken en absoluut nul aandacht te besteden aan hoeveel tijd, CPU-cycles, RAM en bandbreedte dat kost.

Wat is nu concreet de bottleneck die je probeert op te lossen?

Ben je op zoek naar inter-process communication (IPC) tussen verschillende PHP-processen? Dan zijn er wellicht betere oplossingen dan een bestand of database te checken op wijzigingen.

[ Voor 21% gewijzigd door CodeCaster op 19-09-2022 16:45 ]

https://oneerlijkewoz.nl
Op papier is hij aan het tekenen, maar in de praktijk...


Acties:
  • 0 Henk 'm!

  • xilent_xage
  • Registratie: Februari 2005
  • Laatst online: 15-09 11:35
CodeCaster schreef op maandag 19 september 2022 @ 16:43:
Definieer "efficiënt" en "loeiveel overhead". Er moet nou eenmaal een proces een socket openhouden zolang er data te versturen is. Het is namelijk nogal des PHP's om je ontzettend zorgen te maken of een int-parse sneller wordt afgehandeld dan een null-check, om vervolgens twee regels verder een hele databasetabel leeg te trekken en absoluut nul aandacht te besteden aan hoeveel tijd, CPU-cycles, RAM en bandbreedte dat kost.

Wat is nu concreet de bottleneck die je probeert op te lossen?

Ben je op zoek naar inter-process communication (IPC) tussen verschillende PHP-processen? Dan zijn er wellicht betere oplossingen dan een bestand of database te checken op wijzigingen.
Een script dat elke seconde een of meer queries doet of een filemtime checkt voor elke client, lijkt me inefficient in vergelijking met een event-based systeem dat alleen bij een update actie onderneemt.

Acties:
  • 0 Henk 'm!

  • xilent_xage
  • Registratie: Februari 2005
  • Laatst online: 15-09 11:35
CodeCaster schreef op maandag 19 september 2022 @ 16:43:
Ben je op zoek naar inter-process communication (IPC) tussen verschillende PHP-processen? Dan zijn er wellicht betere oplossingen dan een bestand of database te checken op wijzigingen.
Ik had nog nooit van IPC gehoord, maar het klinkt wel goed. Ik zoek echter een php-oplossing zonder gebruik van websockets ivm legacy clients waar ik rekening mee wil houden.

Ik wil dus juist niet een bestand of database checken op wijzgingen, ik wil bij een doorgevoerde wijziging een update sturen van de server naar clients die een long polling request hebben 'openstaan'.

Acties:
  • 0 Henk 'm!

  • Glewellyn
  • Registratie: Januari 2001
  • Laatst online: 29-09 13:57

Glewellyn

is er ook weer.

En hoe ontvangen die clients dan die update? Zijn de clients ook server, luisteren die ook naar requests? Of hebben die permanent een sessie verbonden aan de server?

Het klinkt bijna alsof je zelf een MQTT-broker wil schrijven.

*zucht*


Acties:
  • 0 Henk 'm!

  • xilent_xage
  • Registratie: Februari 2005
  • Laatst online: 15-09 11:35
Glewellyn schreef op maandag 19 september 2022 @ 17:07:
En hoe ontvangen die clients dan die update? Zijn de clients ook server, luisteren die ook naar requests? Of hebben die permanent een sessie verbonden aan de server?

Het klinkt bijna alsof je zelf een MQTT-broker wil schrijven.
Ja dat is dus mijn vraag. Of je die clients (die allemaal nog aan het wachten zijn op de content van de reply) dan vanuit een andere sessie een reply kunt sturen.

Acties:
  • 0 Henk 'm!

  • eLScha
  • Registratie: Juli 2005
  • Niet online
Wat voor legacy systemen praten we over? De Websocket-api werkt al in Intern Explorer 10. Via een tool als Pusher.com hoef je zelfs niet eens infra op te zetten, maar kun je je updates zo naar hem sturen en zij regelen de socket voor je.

Acties:
  • 0 Henk 'm!

  • CodeCaster
  • Registratie: Juni 2003
  • Niet online

CodeCaster

Can I get uhm...

Dus de vraag is hoe een PHP-proces dat aan long-polling doet, dus een verbinding openhoudt om na een request mondjesmaat data te blijven sturen naar een client, op de hoogte gesteld wordt van nieuwe data die door andere processen wordt ontvangen.

En daarvoor kun je inderdaad een database pollen, of een bestand, of een messagequeue, of event-driven werken.

Ik heb geen concreet antwoord op de "hoe", er zijn vast libraries die events kunnen raisen in een runnend proces, kijk naar iets als POSIX-signals. Het event hoeft niet de data an sich te bevatten, maar hoeft enkel een signaal te geven dát er (elders) data beschikbaar is.

Ik denk dat je filemtime een prima oplossing is.

[ Voor 4% gewijzigd door CodeCaster op 19-09-2022 18:03 ]

https://oneerlijkewoz.nl
Op papier is hij aan het tekenen, maar in de praktijk...


Acties:
  • 0 Henk 'm!

  • xilent_xage
  • Registratie: Februari 2005
  • Laatst online: 15-09 11:35
eLScha schreef op maandag 19 september 2022 @ 17:46:
Wat voor legacy systemen praten we over? De Websocket-api werkt al in Intern Explorer 10. Via een tool als Pusher.com hoef je zelfs niet eens infra op te zetten, maar kun je je updates zo naar hem sturen en zij regelen de socket voor je.
Ik werk met een aantal oude tablets (verschillende, oa Galaxy tabs geloof ik) die de interne samsung browser gebruiken. Pusher heb ik al gebruikt en werkt daar niet op.

Acties:
  • 0 Henk 'm!

  • xilent_xage
  • Registratie: Februari 2005
  • Laatst online: 15-09 11:35
CodeCaster schreef op maandag 19 september 2022 @ 17:59:
Dus de vraag is hoe een PHP-proces dat aan long-polling doet, dus een verbinding openhoudt om na een request mondjesmaat data te blijven sturen naar een client, op de hoogte gesteld wordt van nieuwe data die door andere processen wordt ontvangen.
Yep.
CodeCaster schreef op maandag 19 september 2022 @ 17:59:
En daarvoor kun je inderdaad een database pollen, of een bestand, of een messagequeue, of event-driven werken.
Ik zoek dus specifiek naar een methode om event-driven te werken omdat constant serverside pollen en sleepen mij niet heel erg aantrekkelijk lijkt.
CodeCaster schreef op maandag 19 september 2022 @ 17:59:
Ik heb geen concreet antwoord op de "hoe", er zijn vast libraries die events kunnen raisen in een runnend proces, kijk naar iets als POSIX-signals. Het event hoeft niet de data an sich te bevatten, maar hoeft enkel een signaal te geven dát er (elders) data beschikbaar is.
Dat POSIX ziet er best vaag uit, als ik Google kom ik vooral tegen hoe de php module te installeren, en de manual op php.net is ook niet bepaald verhelderend... enig idee waar ik het beste kan beginnen om hierin te duiken om te bepalen of dit een mogelijke oplossing voor mijn probleem is?
CodeCaster schreef op maandag 19 september 2022 @ 17:59:
Ik denk dat je filemtime een prima oplossing is.
Ik denk ook dat ik daar uiteindelijk op ga terugvallen, maar ik probeer dus even uit te vogelen of er een slimmere manier is.

Acties:
  • +1 Henk 'm!

  • eLScha
  • Registratie: Juli 2005
  • Niet online
xilent_xage schreef op maandag 19 september 2022 @ 18:05:
[...]


Ik werk met een aantal oude tablets (verschillende, oa Galaxy tabs geloof ik) die de interne samsung browser gebruiken. Pusher heb ik al gebruikt en werkt daar niet op.
Dan zou ik een topic openen voor ondersteuning daarbij. Pusher bestaat al meer dan 10 jaar. Dat zou je op een Android tablet met Chrome gewoon aan de slag moeten kunnen krijgen.
Pagina: 1