Transfert d'image en TCP pendant un jeu en réseaux

Bonjour à tous et à toutes !

Donc voila, tout est dans le titre.
A l'état où mon projet est; il ne fait que prendre des belles capture d'écran (ce qui déjà pas mal :mouarf:). J'ai déjà pu obtenir un bonne compression avec le format jpeg: Les images ne font que 30 à 60 ko. C'est par la méthode GDI+ que je sauvegardes les captures.

Mais voila, je sollicite votre aide, afin de m'indiquer vers qu'elle direction aller pour la suite:
--> Transférer les captures et autres informations vers un master sans affecter la latence du jeu. Car si le jeu en question est un FPS, hors de question d'avoir des coups de lags !! Comme Punkbuster en fait (Personnes n'auraient son code source ?? :mrgreen:)

Donc quelles fonctions TCP pourraient me permettre de réaliser cela ?
Quelles termes dois-je rechercher ?
Ne serrait-ce pas mieux d'envoyer directement la frame de capture plutôt que l'image enregistré sur le pc client... Je sais pas.

Merci à vous.

Tu as plusieurs possibilités:
Par exemple, faire un client de capture, lancé sur le serveur, qui recevrait les demandes de screens, et ferait les captures en local.

Tu peux aussi transférer l'image lentement (quelques kilos par secondes?).
Ou encore, la transmettre en fin de partie, ou sur les temps morts du joueur (délai de résurrection, menu, fin de partie, etc)

Le problème c'est la quantité de données à transmettre. Si faire la capture ne ralentit pas le joueur, il faut doser le flux parallèle pour ne pas faire laguer violemment

Bonjour et merci de votre réponse.

Citation:

---

Envoyé par leternel

Tu as plusieurs possibilités:
Par exemple, faire un client de capture, lancé sur le serveur, qui recevrait les demandes de screens, et ferait les captures en local.

---

Les captures d'écrans doivent se faire côté client seulement, en effet c'est pour le surveiller.

Citation:

---

Envoyé par leternel

Tu peux aussi transférer l'image lentement (quelques kilos par secondes?).

---

Cela m'intéresse beaucoup, c'est à tester, mais j'ai essayé de trouver sur le net, mais j'ai pas trouvé. Il me faudrait une base en faite, quelque chose de quoi je puisse partir.

Citation:

---

Envoyé par leternel

Ou encore, la transmettre en fin de partie, ou sur les temps morts du joueur (délai de résurrection, menu, fin de partie, etc)

---

Là je suis d'accord aussi, mais je ne vois comment détecter un changements de carte, ou la fin du partie avec le Hooking de directX9.
Si quelqu'un à une idée ?

Citation:

---

Envoyé par leternel

Le problème c'est la quantité de données à transmettre. Si faire la capture ne ralentit pas le joueur, il faut doser le flux parallèle pour ne pas faire laguer violemment

---

Euh là j'ai pas trop compris :aie:

Citation:

---

Envoyé par benjahwest

Bonjour et merci de votre réponse.

Les captures d'écrans doivent se faire côté client seulement, en effet c'est pour le surveiller.

---

Le joueur va adorer l'idée :)

Citation:

---

Envoyé par benjahwest

Cela m'intéresse beaucoup, c'est à tester, mais j'ai essayé de trouver sur le net, mais j'ai pas trouvé. Il me faudrait une base en faite, quelque chose de quoi je puisse partir.

---

C'est de la logique - tu n'as pas besoin de te baser sur le code de qui que ce soit. Tu as une socket TCP ; au lieu d'envoyer toute l'mage directement, tu n'envoie que quelques dizaines - ou centaines d'octets à chaque frame (ou toutes les 10 ms). De cette manière, tu limites l'impact sur l'autre flux de données (les données propres au jeu).

Citation:

---

Envoyé par benjahwest

Là je suis d'accord aussi, mais je ne vois comment détecter un changements de carte, ou la fin du partie avec le Hooking de directX9.
Si quelqu'un à une idée ?

---

Meh ? C'est toi qui fait le jeu, donc tu sais parfaitement lorsqu'une map est terminée - du coté client comme du coté serveur. Si ton serveur n'est pas capable de savoir ça, alors tu risque d'avoir de gros soucis :)

Citation:

---

Envoyé par benjahwest

Euh là j'ai pas trop compris :aie:

---

En gros : QoS, pour quality of service. Tu as deux flux à envoyer : le flux de données correspondant au jeu lui-même (probablement en UDP, n'est-ce pas ?) et le flux TCP contenant l'image. Il te faut trouver un moyen de donner une priorité à chaque flux, de manière à ce que le flux prioritaire passe toujours avec un très faible latence, pendant que le flux non prioritaire envoie ses données petit à petit.

8O Ah j'ai du mal me faire comprendre en fait; Je n'ai pas fait un jeu, loin de là !
J'ai fait un logiciel de capture d'écran, tout ceci est extérieur au jeu. Voila pourquoi je doit hooké le jeu afin d'y parvenir. Une dernière chose, l'utilisateur sera au courant de ce que fera le logiciel car c'est pour un but commun, l'anti-triche.

Mais bon, si j'ai bien compris, en limitant le nombre d'octets lors du transfert donc en TCP, cela me permettrait d'éviter d'affecter le ping du joueur.
Dois-je utiliser TCP NODELAY ou quelque chose comme ça ?

Citation:

---

Envoyé par benjahwest

8O Ah j'ai du mal me faire comprendre en fait; Je n'ai pas fait un jeu, loin de là !
J'ai fait un logiciel de capture d'écran, tout ceci est extérieur au jeu. Voila pourquoi je doit hooké le jeu afin d'y parvenir. Une dernière chose, l'utilisateur sera au courant de ce que fera le logiciel car c'est pour un but commun, l'anti-triche.

Mais bon, si j'ai bien compris, en limitant le nombre d'octets lors du transfert donc en TCP, cela me permettrait d'éviter d'affecter le ping du joueur.
Dois-je utiliser TCP NODELAY ou quelque chose comme ça ?

---

J'avais mal compris :oops:

Sur l'utilisation de TCP NODELAY : non ; ça ne fait pas ce que je pense que tu crois (et par défaut, on est en nodelay dans la plupart des cas).

Il te faut vraiment limiter toi même l'envoi de données sur la socket TCP. Le plus simple : se fixer un budget par seconde (par exemple, 2ko par seconde), découper ça en plusieurs envois (par exemple 10, un toutes les 100 ms), et envoyer un packet de la taille correspondante à chaque envoi.

En pseudo-code :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

t = taille totale de l'image en octets s = socket TCP b = budget par seconde en octets i = buffer image n = nombre d'envoi par seconde   b_envoi = b / n; i_end = i + t; while (i < i_end) { send(s, i, b_envoi); i += b_envoi; sleep_milliseconds(1000 / n); }

---

En choisissant bien b et n, tu peux te retrouver à n'envoyer que des petits paquets TCP, à une fréquence qui ne mettra pas en péril le transfert des données de jeu.

Je n'ai pas tout compris. Où interviens-tu dans cette histoire?

Supposons un jeu en réseau classique, avec ses dix joueurs et son serveur.
De ce que j'ai cru comprendre, chacun des dix postes joueurs lance un programme de captures d'écran pour surveiller les joueurs.
Ce programme est censé envoyer les captures à un serveur qui sera chargé de les comparer.
Si c'est bien cela, ca ressemble diablement à la problématique d'un keylogger.

Une solution, c'est d'avoir une lib de capture vidéo pendant la partie puis chercher l'écran de fin de partie (reconnaissable au panneau de score, au VICTORY, etc) et d'envoyer au serveur ce qui ne l'a pas été depuis la dernière fin de partie (donc la vidéo de la partie).

Mais un anti-triche ne peut pas fonctionner avec l'accord du joueur. Pour qu'il soit utile, cela doit se faire plus ou moins sans son intervention.

Merci pour vos précisions à tout les deux. :ccool: