Bonjour,

A titre d'expérimentation et d'apprentissage, (je n'ai jamais touché à
linternet via Delphi) je souhaite essayer de réaliser un petit jeu qui
devrait permettre à deux joueurs (ou plus) des jouer simultanément sur
un même plateau.

Pour centraliser les requêtes de connexion des joueurs, j'ai idée de
creer un serveur HTTP (en PHP) qui recevra les demandes de connexion
issues du soft (requette HTTP) et répondra dans une page standard les IP
des joueurs disponibles.

Une fois la partie lancée, chaque programme enverra ses mouvement
directement à l'(aux) IP de(s) l'autre(s) partenaire(s).

1) Est-ce que ce schéma est viable ? (en dehors des pb de parefeu qui
vont bloquer les trafic entrant non "requettés").

2) Quelqu'un saurait-il si un script PHP peut envoyer des infos vers une
autre IP que celle qui émet la requete en traitement ? Ou est-ce qu'il
faut créer un serveur dédié pour faire ce genre de manip ? Si oui,
est-il possible d'avoir une piste sur comment le faire en PHP ? (j'ai
trouvé "SocketCreate(...)", et fonctions voisines, mais j'ai des doutes
sur la finalité...)


Tout autre commentaire sera le bienvenu !

D'avance, merci,
Pascal

> A titre d'expérimentation et d'apprentissage, (je n'ai jamais touché à
> linternet via Delphi) je souhaite essayer de réaliser un petit jeu qui
> devrait permettre à deux joueurs (ou plus) des jouer simultanément sur un
> même plateau.
>
> Pour centraliser les requêtes de connexion des joueurs, j'ai idée de creer
> un serveur HTTP (en PHP) qui recevra les demandes de connexion issues du
> soft (requette HTTP) et répondra dans une page standard les IP des joueurs
> disponibles.
>
> Une fois la partie lancée, chaque programme enverra ses mouvement
> directement à l'(aux) IP de(s) l'autre(s) partenaire(s).
>
> 1) Est-ce que ce schéma est viable ? (en dehors des pb de parefeu qui vont
> bloquer les trafic entrant non "requettés").

C'est effectivement une des deux stratégies. Celle que tu as chosie est de
type "peer-to-peer" avec un serveur qui sert juste aux joueurs pour se
trouver les uns les autres. L'autre stratégie consiste à tout faire passer
par le serveur, ce qui résoud le problème des parefeus mais pose problème
dès que le nombre de joueur devient important.


> 2) Quelqu'un saurait-il si un script PHP peut envoyer des infos vers une
> autre IP que celle qui émet la requete en traitement ?

Il ne peut pas. Ce n'est pas lié à PHP, mais au protocole HTTP: le servuer
ne peut jamais prendre l'initiative d'envoyer quelque chose à un client. Il
ne peut que répondre à la reqête d'un client.


> Ou est-ce qu'il faut créer un serveur dédié pour faire ce genre de manip ?

Je pense que la réponse est oui.

> est-il possible d'avoir une piste sur comment le faire en PHP ?

Pourquoi pas en Delphi ?

> Tout autre commentaire sera le bienvenu !

Tu devrais regarder les composants ICS (http://www.overbyte.be).


--
francois.piette@overbyte.be
Auteur du freeware ICS - Internet Component Suite
Auteur du middleware multi-tiers MidWare
web: http://www.overbyte.be
blog: http://francois-piette.blogspot.com

/_Pascal Peyremorte_ a énoncé/ :
> Bonjour,

> A titre d'expérimentation et d'apprentissage, (je n'ai jamais touché à
> linternet via Delphi) je souhaite essayer de réaliser un petit jeu qui
> devrait permettre à deux joueurs (ou plus) des jouer simultanément sur un
> même plateau.

> Pour centraliser les requêtes de connexion des joueurs, j'ai idée de creer un
> serveur HTTP (en PHP) qui recevra les demandes de connexion issues du soft
> (requette HTTP) et répondra dans une page standard les IP des joueurs
> disponibles.

> Une fois la partie lancée, chaque programme enverra ses mouvement directement
> à l'(aux) IP de(s) l'autre(s) partenaire(s).

> 1) Est-ce que ce schéma est viable ? (en dehors des pb de parefeu qui vont
> bloquer les trafic entrant non "requettés").

ça dépend du nombre de connectés simultanément
en dessous d'une dizaine ça devrait aller, au delà, attend toi à des
problèmes je pense

> 2) Quelqu'un saurait-il si un script PHP peut envoyer des infos vers une
> autre IP que celle qui émet la requete en traitement ? Ou est-ce qu'il faut
> créer un serveur dédié pour faire ce genre de manip ? Si oui, est-il possible
> d'avoir une piste sur comment le faire en PHP ? (j'ai trouvé
> "SocketCreate(...)", et fonctions voisines, mais j'ai des doutes sur la
> finalité...)

en php, c'est faisable mais certainement pas conseillé... pour rappel,
le php est un language interprèté. or là tu va avoir besoin d'un
maximum de réactivité.... un serveur dédié est donc nettement plus
indiqué

--
*/Teträm/*
http://www.tetram.org

"De tous ceux qui n'ont rien à dire, les plus agréables sont ceux qui
se taisent." - Coluche

>> 2) Quelqu'un saurait-il si un script PHP peut envoyer des infos vers une
>> autre IP que celle qui émet la requete en traitement ?

> Il ne peut pas. Ce n'est pas lié à PHP, mais au protocole HTTP: le servuer ne
> peut jamais prendre l'initiative d'envoyer quelque chose à un client. Il ne
> peut que répondre à la reqête d'un client.

il existe en php, des fonctions pour ouvrir des sockets sur n'importe
quelle adresse autre que celle du requeteur

--
*/Teträm/*
http://www.tetram.org

"Ecoute toujours ton estomac, c'est quelqu'un de confiance" - Proverbe
Troll

Pascal Peyremorte a écrit :
> Bonjour,
>
> A titre d'expérimentation et d'apprentissage, (je n'ai jamais touché à
> linternet via Delphi) je souhaite essayer de réaliser un petit jeu qui
> devrait permettre à deux joueurs (ou plus) des jouer simultanément sur
> un même plateau.
>
> Pour centraliser les requêtes de connexion des joueurs, j'ai idée de
> creer un serveur HTTP (en PHP) qui recevra les demandes de connexion
> issues du soft (requette HTTP) et répondra dans une page standard les IP
> des joueurs disponibles.

Moi je ferais ca dans un genre de petit service web. HTTP pour le
transport, pourquoi pas même si la surcharge pondérale iduite par HTTP
n'est pas absolument nécessaire dans ton caS.

Je ne choisirais pas PHP. Quitte à démarrer un nouveau projet autant que
ce soit marrant. Et PHP c'est pas marrant, c'est pourri.

Du coup, un petit service web HTTP pourrait renvoyer un bloc XML avec le
type mime qui va bien (text/xml) au lieu d'une "page standard" qu'il te
faudra parser.

> 1) Est-ce que ce schéma est viable ? (en dehors des pb de parefeu qui
> vont bloquer les trafic entrant non "requettés").

Oui, ca permet d'avoir plusieurs types de client, pourquoi pas des
clients Java dans des Applets ou des clients full web 2.0 :-)

> 2) Quelqu'un saurait-il si un script PHP peut envoyer des infos vers une
> autre IP que celle qui émet la requete en traitement ?

Oui, si la configuration du serveur l'autorise.

> Ou est-ce qu'il
> faut créer un serveur dédié pour faire ce genre de manip ? Si oui,
> est-il possible d'avoir une piste sur comment le faire en PHP ? (j'ai
> trouvé "SocketCreate(...)", et fonctions voisines, mais j'ai des doutes
> sur la finalité...)

fsockopen ?

Mais franchement, PHP, c'est naze et c'est has been ;-)

> Moi je ferais ca dans un genre de petit service web. HTTP pour le
> transport, pourquoi pas même si la surcharge pondérale iduite par HTTP
> n'est pas absolument nécessaire dans ton caS.

La charge pondérale induite par le service web est encore bien plus grande.
Générer et parser le XML pour SOAP c'est lourd. Pour un système qui ne doit
pas être interopérable, je n'en vois pas trop l'intérêt si ce n'est
intellectuel.


--
francois.piette@overbyte.be
Auteur du freeware ICS - Internet Component Suite
Auteur du middleware multi-tiers MidWare
web: http://www.overbyte.be
blog: http://francois-piette.blogspot.com

Bonjour,

Francois PIETTE [ICS-MidWare] a écrit :
> C'est effectivement une des deux stratégies. Celle que tu as chosie
> est de type "peer-to-peer" avec un serveur qui sert juste aux joueurs
> pour se trouver les uns les autres. L'autre stratégie consiste à tout
> faire passer par le serveur, ce qui résoud le problème des parefeus
> mais pose problème dès que le nombre de joueur devient important.
J'avais pensé à tout faire transiter par le serveur, non pas pour
résoudre le pb des parefeu (il faudra bien que le serveur envoie un
message à une machine qui n'a rien réclamé, de toute facon, non ?) mais
pour contrôler la validité des mouvement et éviter l'écriture d'un
programme tricheur, car quiconque peut écrire une dll pour remplacer un
"joueur". Mais pour cela le serveur doit pouvoir envoyer des infos à
l'IP du second joueur en même temps qu'il réponds à une requête du premier.

Pour le nombre de joueurs : aucune importance, il n'y en aura jamais
plus de 2 ou 3 dans le pire des cas. Je ne vise pas un truc à grand
trafic et a but commercial. Seulement apprentissage, expérimentation et
fun. Je suis sûr que seuls quelques amis et moi-même l'utiliseront. Dans
le cas contraire, il sera toujours temps de revoir les choses et de
réécrire du "mieux" en profitant de l'expérience acquise.

>> est-il possible d'avoir une piste sur comment le faire en PHP ?
> Pourquoi pas en Delphi ?
Parce que je n'ai aucune idée de comment faire exécuter une routine
delphi par un des deux serveurs à ma disposition. Je doute que celui de
chez Free accepte ce genre de routine qui pourrait le planter par une
simple boucle sans fin, pas plus que celui sur lequel on m'a ouvert un
hébergement gratuitement pour services rendus...
Par contre j'ai un peu découvert PHP pour ma page des partitions. Je le
trouve assez marrant et somme toute pas mal puissant à défaut de rapide. :-)

> Tu devrais regarder les composants ICS (http://www.overbyte.be).
Bien sûr ! J'ai /déjà/ commencé à regarder les composant ICS. Mais je ne
sais pas si je vais les utiliser : ils sont vraiment trop mal écrit et
leur prix d'enregistrement est vraiment trop exorbitant.
:-) :-P :-D O:-)

Non, sérieusement : ils sont très bien !

Merci Francois, pour toutes ces infos (et ledit ICS) !
Pascal

> (il faudra bien que le serveur envoie un message à une machine
> qui n'a rien réclamé, de toute facon, non ?)

pas forcément... la connexion peut avoir été établie en amont par le
client, et "inversée" par la suite

--
*/Teträm/*
http://www.tetram.org

"Tape d'abord, tape ensuite, et tape pour finir" - Proverbe Troll

Faust a écrit :
>> (il faudra bien que le serveur envoie un message à une machine qui
>> n'a rien réclamé, de toute facon, non ?)
>
> pas forcément... la connexion peut avoir été établie en amont par le
> client, et "inversée" par la suite
>
Hoho, v'la des choses que je n'imaginais même pas.
Est-ce que tu aurais aurais quelques lien ou référence de doc là dessus ?
Merci !

Faust a écrit :
> /_Pascal Peyremorte_ a énoncé/ :
>
>> 1) Est-ce que ce schéma est viable ? (en dehors des pb de parefeu qui
>> vont bloquer les trafic entrant non "requettés").
> ça dépend du nombre de connectés simultanément
> en dessous d'une dizaine ça devrait aller, au delà, attend toi à des
> problèmes je pense
C'est compatible !

>
>> 2) Quelqu'un saurait-il si un script PHP peut envoyer des infos vers
>> une autre IP que celle qui émet la requete en traitement ? Ou est-ce
>> qu'il faut créer un serveur dédié pour faire ce genre de manip ? Si
>> oui, est-il possible d'avoir une piste sur comment le faire en PHP ?
>> (j'ai trouvé "SocketCreate(...)", et fonctions voisines, mais j'ai
>> des doutes sur la finalité...)
>
> en php, c'est faisable mais certainement pas conseillé... pour rappel,
> le php est un language interprèté. or là tu va avoir besoin d'un
> maximum de réactivité.... un serveur dédié est donc nettement plus
> indiqué
bah, Je ne suis pas pressé! Voir ma réponse à François, un brin plus haut...

Merci pour ces informations. Il va y avoir de l'expérimentation dans
l'air !!!
Pascal

Pierre Y. a écrit :
> Je ne choisirais pas PHP. Quitte à démarrer un nouveau projet autant
> que ce soit marrant. Et PHP c'est pas marrant, c'est pourri.
Ben... j'ai construit une partie de mon moeste site (la page des
partitions) en PHP, avec des lectures binaires dans les fichiers, et..,
et je me suis bien amusé ! Comme quoi, on trouve tous les avis dans la
nature. :-)

Je ne l'ai trouvé ni pourri, ni naze. Bien sûr, il est interprété, mais
il a un avantage : je sais qu'il fonctionne et comment l'exploiter, même
si je ne le maitrise pas ! Pour un premier pas, c'est ce qui me sera le
plus facile. Après, on verra bien...

Pour l'instant, le seul client envisagé est en delphi Win32.

Merci pour ton avis.
Pascal

Francois PIETTE [ICS-MidWare] a écrit :
>> Moi je ferais ca dans un genre de petit service web. HTTP pour le
>> transport, pourquoi pas même si la surcharge pondérale iduite par HTTP
>> n'est pas absolument nécessaire dans ton caS.
>
> La charge pondérale induite par le service web est encore bien plus
> grande. Générer et parser le XML pour SOAP c'est lourd. Pour un système
> qui ne doit pas être interopérable, je n'en vois pas trop l'intérêt si
> ce n'est intellectuel.

Désolé, je ne concois plus de système dont la fonctionnalité essentielle
est d'être multiplateforme et intéropérable, ca ne m'intéresse plus.

Pascal Peyremorte a écrit :
> Pierre Y. a écrit :
>> Je ne choisirais pas PHP. Quitte à démarrer un nouveau projet autant
>> que ce soit marrant. Et PHP c'est pas marrant, c'est pourri.
> Ben... j'ai construit une partie de mon moeste site (la page des
> partitions) en PHP, avec des lectures binaires dans les fichiers, et..,
> et je me suis bien amusé ! Comme quoi, on trouve tous les avis dans la
> nature. :-)

Les joies de pack/unpack :-)

> Je ne l'ai trouvé ni pourri, ni naze. Bien sûr, il est interprété, mais
> il a un avantage : je sais qu'il fonctionne et comment l'exploiter, même
> si je ne le maitrise pas ! Pour un premier pas, c'est ce qui me sera le
> plus facile. Après, on verra bien...

"A titre d'expérimentation et d'apprentissage,..." par définition dans
ce genre de situation on ne cherche pas à faire des choses "faciles"
sinon c'est pas rigolo.

> Pour l'instant, le seul client envisagé est en delphi Win32.

Quel dommage, moi qui linuxe à la maison je ne pourrai donc pas y jouer
à ton jeu :-(

>>> Moi je ferais ca dans un genre de petit service web. HTTP pour le
>>> transport, pourquoi pas même si la surcharge pondérale iduite par HTTP
>>> n'est pas absolument nécessaire dans ton caS.
>>
>> La charge pondérale induite par le service web est encore bien plus
>> grande. Générer et parser le XML pour SOAP c'est lourd. Pour un système
>> qui ne doit pas être interopérable, je n'en vois pas trop l'intérêt si ce
>> n'est intellectuel.
>
> Désolé, je ne concois plus de système dont la fonctionnalité essentielle
> est d'être multiplateforme et intéropérable, ca ne m'intéresse plus.

N'était-ce pas le contraire que tu voulais dire ? Relis un peu ced que tu as
écrit et ce que j'ai écrit parce que moi je crois comprendre le contraire de
ce que tu semble vouloir dire :-)

--
francois.piette@overbyte.be
The author of the freeware multi-tier middleware MidWare
The author of the freeware Internet Component Suite (ICS)
http://www.overbyte.be

Francois PIETTE [ICS-MidWare] a écrit :
> N'était-ce pas le contraire que tu voulais dire ? Relis un peu ced que
> tu as écrit et ce que j'ai écrit parce que moi je crois comprendre le
> contraire de ce que tu semble vouloir dire :-)

sur le coup c'était très drôle

Francois PIETTE [ICS-MidWare] a écrit :
>>>> Moi je ferais ca dans un genre de petit service web. HTTP pour le
>>>> transport, pourquoi pas même si la surcharge pondérale iduite par
>>>> HTTP n'est pas absolument nécessaire dans ton caS.
>>>
>>> La charge pondérale induite par le service web est encore bien plus
>>> grande. Générer et parser le XML pour SOAP c'est lourd. Pour un
>>> système qui ne doit pas être interopérable, je n'en vois pas trop
>>> l'intérêt si ce n'est intellectuel.
>>
>> Désolé, je ne concois plus de système dont la fonctionnalité
>> essentielle est d'être multiplateforme et intéropérable, ca ne
>> m'intéresse plus.
>
> N'était-ce pas le contraire que tu voulais dire ? Relis un peu ced que
> tu as écrit et ce que j'ai écrit parce que moi je crois comprendre le
> contraire de ce que tu semble vouloir dire :-)

Et merde, bien vu...

Pierre Y. a écrit :
> Francois PIETTE [ICS-MidWare] a écrit :
>>> Moi je ferais ca dans un genre de petit service web. HTTP pour le
>>> transport, pourquoi pas même si la surcharge pondérale iduite par
>>> HTTP n'est pas absolument nécessaire dans ton caS.
>>
>> La charge pondérale induite par le service web est encore bien plus
>> grande. Générer et parser le XML pour SOAP c'est lourd. Pour un
>> système qui ne doit pas être interopérable, je n'en vois pas trop
>> l'intérêt si ce n'est intellectuel.

Bon, je crois que je devrais me relire plus souvent...

Désolé, je ne concois plus de système dont la fonctionnalité essentielle
N'est PAS d'être multiplateforme et intéropérable, ca ne m'intéresse plus.

/Il se trouve que _Pascal Peyremorte_ a tapoté/ :
> Faust a écrit :
>>> (il faudra bien que le serveur envoie un message à une machine qui n'a
>>> rien réclamé, de toute facon, non ?)
>>
>> pas forcément... la connexion peut avoir été établie en amont par le
>> client, et "inversée" par la suite
>>
> Hoho, v'la des choses que je n'imaginais même pas.
> Est-ce que tu aurais aurais quelques lien ou référence de doc là dessus ?
> Merci !

malheureusement non, mais ça m'étonnerais que François ne puisse pas
t'expliquer comment faire avec les ICS

--
*/Teträm/*
http://www.tetram.org

"Quand le Troll parle,
L'homme avisé l'écoute"

Faust a écrit :
> /Il se trouve que _Pascal Peyremorte_ a tapoté/ :
>> Faust a écrit :
>>>> (il faudra bien que le serveur envoie un message à une machine qui
>>>> n'a rien réclamé, de toute facon, non ?)
>>> pas forcément... la connexion peut avoir été établie en amont par le
>>> client, et "inversée" par la suite
>> Hoho, v'la des choses que je n'imaginais même pas.
>> Est-ce que tu aurais aurais quelques lien ou référence de doc là
>> dessus ?
>> Merci !
> malheureusement non, mais ça m'étonnerais que François ne puisse pas
> t'expliquer comment faire avec les ICS
C'est pas grave. Je poserai la question ici si je ne trouve rien là
dessus. Mais c'est un peu prématuré : j'ai déjà de quoi chercher et
découvrir pour les prochaines semaines !

A bientôt et merci quand même!
Pascal

Hello !

Pascal Peyremorte a écrit :
> Bonjour,
>
> A titre d'expérimentation et d'apprentissage, (je n'ai jamais touché à
> linternet via Delphi) je souhaite essayer de réaliser un petit jeu qui
> devrait permettre à deux joueurs (ou plus) des jouer simultanément sur
> un même plateau.

ok

> Pour centraliser les requêtes de connexion des joueurs, j'ai idée de
> creer un serveur HTTP (en PHP) qui recevra les demandes de connexion
> issues du soft (requette HTTP) et répondra dans une page standard les IP
> des joueurs disponibles.

oui c'est pas compliqué à faire

> Une fois la partie lancée, chaque programme enverra ses mouvement
> directement à l'(aux) IP de(s) l'autre(s) partenaire(s).

là tu as le soucis des joueurs qui sont avec une adresse IP privée
derrière un routeur. Ils sont capables d'appeler le serveur Web, mais
pas de recevoir de requête.

j'ai fait un blabla sur le sujet
http://lookinside.free.fr/delphi.php?Socket

> 1) Est-ce que ce schéma est viable ? (en dehors des pb de parefeu qui
> vont bloquer les trafic entrant non "requettés").

oui, mis à part le pb des adresses privées

> 2) Quelqu'un saurait-il si un script PHP peut envoyer des infos vers une
> autre IP que celle qui émet la requete en traitement ? Ou est-ce qu'il
> faut créer un serveur dédié pour faire ce genre de manip ? Si oui,
> est-il possible d'avoir une piste sur comment le faire en PHP ? (j'ai
> trouvé "SocketCreate(...)", et fonctions voisines, mais j'ai des doutes
> sur la finalité...)

oui, tu peux très bien utiliser un script PHP pour ouvrir un socket.
le seul soucis c'est que ton script va finir par se terminer...et la
connexion avec lui.

mais on peut faire déjà des choses sympas, par exemple entre mes sites
http://tothpaul.free.fr/ et http://www.zoo-logique.org/tothpaul j'ai un
script PHP que je peux invoquer sur l'un des deux sites pour qu'il aille
chercher les mises à jour sur l'autre (via un second script) : mon poste
invoque le script, le script se connecte sur le second serveur pour
récupérer la mise à jour et il me répond OK.
j'y ai mis un minimum de sécurité avec un filtrage par adresse IP et
l'usage d'un mot de passe entre les deux sites

>
> Tout autre commentaire sera le bienvenu !

ton client Delphi peut s'enregister sur le serveur PHP en indiquant un
numéro de port sur lequel il est à l'écoute (avec une Freebox - ou tout
autre routeur - configurée correctement, le pb des adresses privées n'en
est plus un). Le script peut ouvrir un socket sur le port indiqué pour
le valider avant d'enregistrer le client en local (BDD ou flat file).

là tu peux aussi demander au script PHP de revalider tous les clients
existants histoire d'épurer les clients qui ne se sont pas déinscrits
sur le site...tu peux au passage leur donner l'@IP du nouveau client et
les laisser le contacter...ou retourner à ce nouveau client la liste des
clients validés.

un mode de fonctionnement qu'il faudrait tester, c'est que lorsqu'un
client invoque le serveur PHP pour lui donner un ordre (déplacement,
etc..) ça serait au script de propager cette information à tous les
clients recensés. Sinon c'est à chaque client de pooler régulièrement le
serveur pour obtenir les mise à jours.

> D'avance, merci,
> Pascal

bon amusement

Paul TOTH a écrit :
> là tu as le soucis des joueurs qui sont avec une adresse IP privée
> derrière un routeur. Ils sont capables d'appeler le serveur Web, mais
> pas de recevoir de requête.
>
> j'ai fait un blabla sur le sujet
> http://lookinside.free.fr/delphi.php?Socket
Super !

>> 2) Quelqu'un saurait-il si un script PHP peut envoyer des infos vers
>> une autre IP que celle qui émet la requete en traitement ? Ou est-ce
>> qu'il faut créer un serveur dédié pour faire ce genre de manip ? Si
>> oui, est-il possible d'avoir une piste sur comment le faire en PHP ?
>> (j'ai trouvé "SocketCreate(...)", et fonctions voisines, mais j'ai
>> des doutes sur la finalité...)
> oui, tu peux très bien utiliser un script PHP pour ouvrir un socket.
> le seul soucis c'est que ton script va finir par se terminer...et la
> connexion avec lui.
Je pensais ouvrir le socket, envoyer un paquet "Données à lire", et le
refermer tout de suite. A charge du client d'interroger de serveur. Une
espèce de polling sur demande. :-)
Ce qui n'empèche pas le client de scruter périodiquement -ou sur clic
utilisateur- s'il ne reçoit rien pendant trop longtemps.

> bon amusement
Ca va le faire !

Merci pour toutes ces informations et idées.
Comme tu l'as peut-être deviné, le "jeu test" sera schlurp. J'étendrai
après à d'autres (Othello, NCR, Dames, pour lesquels j'ai déjà le
plateau), sur le même principe si j'arrive à faire fonctionner tout ça.

A suivre...
Pascal

Pascal Peyremorte a écrit :
> Paul TOTH a écrit :
>> là tu as le soucis des joueurs qui sont avec une adresse IP privée
>> derrière un routeur. Ils sont capables d'appeler le serveur Web, mais
>> pas de recevoir de requête.
>>
>> j'ai fait un blabla sur le sujet
>> http://lookinside.free.fr/delphi.php?Socket
> Super !
>
>>> 2) Quelqu'un saurait-il si un script PHP peut envoyer des infos vers
>>> une autre IP que celle qui émet la requete en traitement ? Ou est-ce
>>> qu'il faut créer un serveur dédié pour faire ce genre de manip ? Si
>>> oui, est-il possible d'avoir une piste sur comment le faire en PHP ?
>>> (j'ai trouvé "SocketCreate(...)", et fonctions voisines, mais j'ai
>>> des doutes sur la finalité...)
>> oui, tu peux très bien utiliser un script PHP pour ouvrir un socket.
>> le seul soucis c'est que ton script va finir par se terminer...et la
>> connexion avec lui.
> Je pensais ouvrir le socket, envoyer un paquet "Données à lire", et le
> refermer tout de suite. A charge du client d'interroger de serveur. Une
> espèce de polling sur demande. :-)
> Ce qui n'empèche pas le client de scruter périodiquement -ou sur clic
> utilisateur- s'il ne reçoit rien pendant trop longtemps.
>
>> bon amusement
> Ca va le faire !
>
> Merci pour toutes ces informations et idées.
> Comme tu l'as peut-être deviné, le "jeu test" sera schlurp. J'étendrai
> après à d'autres (Othello, NCR, Dames, pour lesquels j'ai déjà le
> plateau), sur le même principe si j'arrive à faire fonctionner tout ça.

héhé, ça nous rajeuni pas tout ça

ben oui pour ce genre de choses, c'est pas compliqué en fait.
sur ton serveur PHP tu stockes les sessions de jeux, l'état de la
partie, chaque joueur peu relire cet état, et quand s'est son tour, le
joueur peu donner un ordre

sur developpez.com tu trouveras DelPHP aussi (ou un nom comme ça) qui
propose d'interfacer du code PHP d'un côté et du client Delphi de
l'autre justement.

> A suivre...
> Pascal