Salut,
Non, ce n'est pas du long polling, car tu ne boucle tout simplement pas. Il n'y a pas de notion de "les connexion rapide influent les connexion lentes": tu es côté serveur, donc, c'est ton algo qui dirige les choses, pas le client. De plus, il n'y a pas de "race condition": étant transactionné, t'as pas de soucis côté DB (mis à part qu'il faut paramétrer tes queries et non faire de la concaténation de string
)
Ca peut être sympa d'avoir un service "jeuweb" pour ça, oui, mais après, faudra le monitorer car si on se retrouve avec des mauvais codes ou des jeux à 10k joueurs, on va coincer :/ Il faudra aussi être capable de bien gérer le fait d'être sur 2 origines différentes (jeuweb.org & urldujeu.com) Le même soucis d'origine se pose si tu prends un dédié en plus de ton mutu (c'est con IMO, mieux vaut alors ne prendre qu'un dédié), même si la "casse" est limitée puisque tu peux faire pointer un sous domaine du jeu sur ce dédié.
Le serveur dédié peut être en ce que tu veux. Faut qu'il soit en revanche capable de gérer les websockets, et idéalement, de gérer les évent (de sorte que la connexion 2 puisse dire à la connexion 1 que le joueur de la connexion 2 est arrivé dans le lieu X), sinon, tu vas te retrouver avec de l'attente active côté serveur, ce qui n'amènera donc rien d'intéressant.
Hum, un dédié, à part les kimsuffi, je les voit plutôt à 10€ le mois : )
Y'a pas de "table" dans le serveur JS. Ton serveur JS aura juste à aller se connecter au SQL commun aux deux serveurs pour lire les données dont il a besoin (à toi derrière de gérer tes transactions proprement : ) Non, je dis ça "comme ça", juste parce que ce genre d'archi, c'est ce qu'on adore au boulot et qu'on se retrouve avec 10 serveurs Java pour la moindre requête entrante, qui se marchent tous dessus dans leurs appels de BDD ce qui fait qu'on n'a plus vraiment de transaction... je m'égare, pardon).
Tiens, d'ailleurs, pour ceux qui se sont servi de NodeJS, comment ça se passe quand la connexion 2 doit informer les autres d'un event (genre, le joueur de la connexion 2 est arrivé dans le lieu X)? La connexion dispatch un event sur un objet global genre "Server", et toutes les autres connexions avec un listener dessus peuvent réagir à l'event? Si oui, ça se passe comment quand on atteint 10,100,1000,10k connexions (parce que là, ça devient juste ingérable par un serveur?!)? Quelle "limite" pratique au nb de connexions dans ce cas?
Edit:
Eeeeeh, je ne m'en suis jamais servi, mais les mutualisés d'OVH semblent avoir le module Semaphore d'actif ( http://fpm7.3-check.cluster013.hosting.o...hpinfo.php sysvmsg) donc, il serait possible de l'utiliser pour faire de l'IPC (Inter Process Communication si j'ia bien tout suivi https://www.php.net/manual/en/ref.sem.php ) ce qui permettrait à un script PHP de "notifier" un autre script qu'un évènement a eu lieu... Cela pourrait faire un long polling intéressant ?!
Non, ce n'est pas du long polling, car tu ne boucle tout simplement pas. Il n'y a pas de notion de "les connexion rapide influent les connexion lentes": tu es côté serveur, donc, c'est ton algo qui dirige les choses, pas le client. De plus, il n'y a pas de "race condition": étant transactionné, t'as pas de soucis côté DB (mis à part qu'il faut paramétrer tes queries et non faire de la concaténation de string
)Ca peut être sympa d'avoir un service "jeuweb" pour ça, oui, mais après, faudra le monitorer car si on se retrouve avec des mauvais codes ou des jeux à 10k joueurs, on va coincer :/ Il faudra aussi être capable de bien gérer le fait d'être sur 2 origines différentes (jeuweb.org & urldujeu.com) Le même soucis d'origine se pose si tu prends un dédié en plus de ton mutu (c'est con IMO, mieux vaut alors ne prendre qu'un dédié), même si la "casse" est limitée puisque tu peux faire pointer un sous domaine du jeu sur ce dédié.
Le serveur dédié peut être en ce que tu veux. Faut qu'il soit en revanche capable de gérer les websockets, et idéalement, de gérer les évent (de sorte que la connexion 2 puisse dire à la connexion 1 que le joueur de la connexion 2 est arrivé dans le lieu X), sinon, tu vas te retrouver avec de l'attente active côté serveur, ce qui n'amènera donc rien d'intéressant.
Hum, un dédié, à part les kimsuffi, je les voit plutôt à 10€ le mois : )
Y'a pas de "table" dans le serveur JS. Ton serveur JS aura juste à aller se connecter au SQL commun aux deux serveurs pour lire les données dont il a besoin (à toi derrière de gérer tes transactions proprement : ) Non, je dis ça "comme ça", juste parce que ce genre d'archi, c'est ce qu'on adore au boulot et qu'on se retrouve avec 10 serveurs Java pour la moindre requête entrante, qui se marchent tous dessus dans leurs appels de BDD ce qui fait qu'on n'a plus vraiment de transaction... je m'égare, pardon).
Tiens, d'ailleurs, pour ceux qui se sont servi de NodeJS, comment ça se passe quand la connexion 2 doit informer les autres d'un event (genre, le joueur de la connexion 2 est arrivé dans le lieu X)? La connexion dispatch un event sur un objet global genre "Server", et toutes les autres connexions avec un listener dessus peuvent réagir à l'event? Si oui, ça se passe comment quand on atteint 10,100,1000,10k connexions (parce que là, ça devient juste ingérable par un serveur?!)? Quelle "limite" pratique au nb de connexions dans ce cas?
Edit:
Eeeeeh, je ne m'en suis jamais servi, mais les mutualisés d'OVH semblent avoir le module Semaphore d'actif ( http://fpm7.3-check.cluster013.hosting.o...hpinfo.php sysvmsg) donc, il serait possible de l'utiliser pour faire de l'IPC (Inter Process Communication si j'ia bien tout suivi https://www.php.net/manual/en/ref.sem.php ) ce qui permettrait à un script PHP de "notifier" un autre script qu'un évènement a eu lieu... Cela pourrait faire un long polling intéressant ?!