Chaque application Symfony utiles sur le plan d'une forme d'E/S. Dans les applications traditionnelles, cela bloque le plus souvent les E/S. Même s'il s'agit d'E/S non bloquantes, il n'intègre pas de boucle d'événements globale qui pourrait planifier d'autres choses en attendant les E/S. Si vous intégrez Symfony dans un serveur WebSocket basé sur une boucle d'événements, il fonctionnera avec le blocage des E/S comme preuve de concept, mais vous remarquerez rapidement qu'il ne fonctionne pas correctement en production, car tout blocage I/O bloque toute votre boucle d'événements et bloque ainsi tous les autres clients connectés. Une solution consiste à tout réécrire en E/S non bloquantes, mais vous n'utiliserez plus Symfony. Vous pourriez être en mesure de réutiliser certains composants, mais seulement ceux qui ne font pas d'E/S.
Une autre solution consiste à utiliser des demandes RPC et de file d'attente WebSocket dans une file d'attente. L'intermédiaire peut être écrit en n'utilisant que des E/S non bloquantes, il n'a pas grand chose à faire. Il transmet simplement les messages WebSocket en tant que demandes RPC à une file d'attente. Ensuite, vous avez un ensemble de travailleurs tirant de cette file d'attente, faisant un envoi normal du noyau Symfony et envoyant la réponse dans une file d'attente de réponses. Le travailleur peut alors continuer à aller chercher le prochain travail. Avec la deuxième solution, vous pouvez utiliser totalement les E/S bloquantes et tous les composants Symfony existants. Vous pouvez générer autant de travailleurs que vous avez besoin et vous pouvez même les garder en vie entre les demandes. La différence avec une file d'attente intermédiaire est qu'un seul bloqueur ne bloque pas la réactivité du point de terminaison WebSocket.
Si vous souhaitez utiliser plusieurs processus WebSocket, vous devez disposer de files d'attente de réponses distinctes. Les réponses sont donc renvoyées au bon processus où le client est connecté.
Vous pouvez trouver une implémentation de travail avec BeanstalkD comme file d'attente dans kelunik/rpc-demo. src/Server.php est juste pour le but de démonstration et peut être remplacé par un serveur HTTP à tout moment. Pour garder la démo simple, il utilise un seul processus WebSocket, mais cela peut être modifié comme indiqué ci-dessus. Vous pouvez démarrer php bin/server et php bin/worker, puis utiliser telnet localhost 2000 pour vous connecter et envoyer des messages. Il répondra avec le même message mais base64 codé dans les travailleurs.
La démo mentionnée est construite sur Amp, mais les mêmes concepts s'appliquent à ReactPHP.
Merci, Mais comme je m'y attendais pour le moment, Symfony ne propose pas une méthode simple pour une application en temps réel –