Discussion :

[k'n1]

Salut a tous,

j'espere poster au bon endroit, je n'ai pas encore eu le temps de tout fouiller mais je prefere lancer mon topic maintenant histoire d'avoir une reponse (au moins ^_^) quand j'aurais un peu creuse dans le site

J'attaque en ce moment un stage, en coree ^_^, ou je dois faire des trucs qui parlent de serveur pour un jeu video.... donc je risque d'avoir un petit paquet de questions dans les mois a venir, voici la premiere et j'espere que je vous ennuierai pas trop souvent avec mes probleme ^_^

Le jeu a ete prog en C++. Du coup, etant un peu novice en c++ je passe ici pour avoir quelques infos :

- programmation reseau en c++ (rhaa ca fait 3 fois que j ecris java au lieu de c++, c est pas bon les habitudes), pour du lan en utilisant un protocole tcp/ip ou ipx, ca se fait comment ? existe t il des libraires comme en java poru eviter de se prendre la tete sur la prog reseau elle meme ? ^_^
- idem mais dans une architecture client serveur sur le net cette fois (en gros, mes serveurs locaux discutent entre eux par le biais du serveur central), en tapant sur des morceaux de base SQL certainement... ca se fait bien ? comment ? avec quoi ? quel est l age du capitaine ?

- enfin, 2e solution si j arrive pas a trovuer comment on fait en c : faire communiquer mes clients en C++ avec un serveur en java, pour cela je pensais faire appel a CORBA, donc est ce une bonne idee ? y a t il d autre solutions ? ca donne quoi en c++ a ce niveau (pareil j y connais rien) ?
- et dans ce cas, j utiliserai pour la partie net du java aussi, je pensais aux EJB... bonne idee ? autre chose ?

voila pour mes questions ... bon la partie java est pas essentielle, le reve serait de tout faire en c++ avec des gros tutoriels ou on me dit comment tout faire, mais bon je prefere pas trop rever et j'attend simplement quelques reponses

sur ce, je repars dans ma traque de l'information, soulage en tout cas que cette fois ci je n'aie pas a programmer en ce foutu visual basic (bien que j'ai un collegue qui voulait m orienter la dessus, mais il etait seul donc ca a fini comme 3e solution que je ne prefere meme pas exposer ici )

a bientot et merci d'avance !

[Jan Rendek]

Pour la modique somme de 10kEuros, je te fais l'audit, le code et le rapport qui va avec.

Les quelques rédacteurs et les nombreux lecteurs de ce forum, ne t'en voudront pas de les ennuyer avec tes problèmes, mais t'en voudront sûrement de poser des questions vagues, sans avoir chercher les réponses par toi même au préalable.

Enfin pour les quelques problèmes que tu soulèves voilà quelques éléments de réponse.
La programmation réseau ne fait pas partie du langage C++. Elle repose sur l'utilisation de bibliothèques, qui elles-même reposent de près ou de loin sur l'implémentation les sockets type BSD.

Pour le reste, il est difficile de te conseiller sur une architecture réseau sans connaître le cahier des charges. De même, il est difficile de se prononcer sur comment faire communiquer les différents clients, sans savoir quelles sont le type et le volume de données à acheminer.
On ne construit pas un immeuble de 10 étages avec les même techniques que pour une cabane de jardin.

[Fry]

pas cher pas cher

sinon bon utiliser les reseau TCP/IP en C++ tu dois utiliser une librairie qui depend du systeme d exploitation ou tourne le programme
par exemple sous windows il faut utiliser l API winsock

[mtopoloff]

En C++ sous windows, pour du jeu en reseau, je te conseille fortement d'utiliser DirectPlay (DirectX)

[k'n1]

Salut,

tout d'abord merci pour les reponses et toutes mes excuses si je suis trop vague... c'est que je mene mes recherches de mon cote, j'en suis encore qu'au debut donc je me dis qu'un bout de piste egaree, par exemple un lien vers un tuto que j'aurais loupe pourrait se trouver quelque part ...

10k euros ? j'aimerai bien etre paye cette somme ^_^ ...

En ce qui concerne les bibliotheques en C++ pour le reseau, c'est il me semble la meme chose que les package utilises en java pour faire relativement la meme chose (RMI, EJB etc..) n'est ce pas (hop, C++ noob inside ^_^) ? dans ce cas la, pour ma part je le considere comme partie integrante du langage, desole pour la confusion.

En ce qui concerne l'architecture, je l'etudie actuellement (le cahier des charges sera plutot un... cahier a ma charge, on va dire ^_^)... donc ca donne un certain nombre de stations (j'estime a la louche le nombre a 2-15) reliees a un serveur par un LAN classique (donc utilisation de TCP/IP ou de IPX en local selon ce qui est faisable, et selon la facon dont les fameux socket sont configurables a ce niveau ?) ... les stations sont principalement des unites graphiques, le serveur serait une machine surtout destinee a la communication et au management des stations, donc pas une tres grosse becane.. le debit d'informations serait a mon avis relativement raisonnable, car les parties se font a une dizaine de joueur maxi et le jeu est relativement simple. donc ce n'est pas un mmorpg ... par contre a l avenir il est possible que j'ai a implementer un chat vocal sur ce projet ou un autre, donc une interface ouverte serait souhaitable si je veux pas me faire pieger..

En ce qui concerne la partie internet, c'est a present le serveur precedent qui est relie a un serveur principal, qui detient les cles de la BDD (profils des users notamment). Les communications sont donc celles du jeu, ainsi que diverses donnees receuillies en fin de partie pour alimenter la DB et faire des stats (voir un peu de datamining mais bon ca c'est mon cadeau bonus si j'arrive faire le reste, ca me motive a essayer de finir ca vite et bien pour me plonger vraiment dans mon domaine ). Bon a ce niveau la, qui dit internet dit TCP/IP (la je crois pas trop me tromper), pas de grande surprise, par contre on peut compter sur une bonne connection des serveurs dans un premier temps, puisque l'application tournerait principalement en coree (peut etre dans un second temps aux etats unis..)

Voila les bases de l'architecture, je voulais pas en mettre trop sur mon premier message pour eviter d'harasser les bonnes volontes qui m'auraient lu ^_^... de meme je prefere pas mettre de details ici en terme de specs, ca reste un projet professionnel donc j'evite de m'etendre .. donc questions en privees pour plus de details, reponse en public si ca me parait utile.

Winsock ok je retiens... ha oui, stations - serveurs - serveur principal, tout tourne sous windows a ma connaissance.

Directplay ? ok merci j'etudie le cas aussi...

je me sens un peu a un croisement de 10 chemins qui partent on ne sais ou, mais bon ca devrait s'eclaircir avec le temps je pense

en tout cas, ma question principale a l'heure actuelle serait :

- vaut il mieux prog mon reseau via c++ pour avoir la meme plateform partout (jeu et reseau) ?
- serait il plus judicieux de prog le reseau en java, relativement plus simple je crois a ce niveau (d'autant plus que je suis moins noob en java ^_^) et faire une passerelle de communication avec c++ pour que les donnees du reseau soit communiquees au jeu et vice-versa ?

ps: j'aimerai bien etendre mes competence de prog a c++ d'ou mon dilemne, mais si c'est trop complique a mettre en place, et que java peut faire l'affaire, je me replierai vers cette seconde solution.

pps: desole pour la longueur du post

[k'n1]

snif je le savais qu'un message trop long tuerai mon topic

Bon sinon j'ai teste winsock vite fait, mis a part que ca deconne un peu dans mon prog de test (buffer rempli de pleins de symboles etranges apres le message recu, et message recu partiellement seulement je sais pas pourquoi), ca a l'air de se gerer plutot bien.

je vais regarder maintenant Directplay qui peut s appuyer sur du IPX je crois, chose bien pratique en local (adresse mac, rapidite..).. si j'arrive a trouver comment l'utiliser. Pas moyen d'avoir un tuto la dessus, si vous avez une adresse ca m interesse fortement

[JolyLoic]

winsock, c'est vague. Pour des applis genre jeu en local, ça peut être intéressant de regarder de plus près UDP et multicast.

[k'n1]

avec Winsock si tu fais un sendto() ca utilise le protocole UDP n'est ce pas ? (non connecte) par contre par multicast tu entends quoi ? broadcast par IP, ou bien le nom d'une autre API ?

je suis en train de regarder direct play, la doc fourni avec est enorme ! y a tout dedans, des concepts aux samples en passant par des tuto et du code ... a mon avis mon bonheur va se trouver la dedans ^_^

dernier detail sur mon projet : pas besoin d'etre portable, le jeu est livre avec une machine de type PC charge en windows, et les serveur sont de type win aussi... donc on peut exploiter ca a fond, facon borne d'arcade en gros ^_^

[mtopoloff]

Re !

Je proclame DIRECTPLAY ! C'est un outil specialisé pour les jeux en reseau (Serveur, clients, VoIP....)

http://www.deersoftware.com/gamedev.php

Et puis MSDN !!

[k'n1]

merci pour le lien, ca va m'etre utile je crois

bon j'approfondi ma recherche directplay et on en reparle ^_^

si vous avez d'autre adresses et conseils n'hesitez pas !

[SKZ81]

10k euros ? j'aimerai bien etre paye cette somme ^_^ ...

Hé le stagiaire qui se la ramène... ...Je rigole bien sûr, j'ai fait la même réflexion à l'époque (Y'a tout juste deux ans...).

dans ce cas la, pour ma part je le considere comme partie integrante du langage, desole pour la confusion.

[blah-blahtage historique]
stricto sensus un language est défini par une grammaire. C'est avec l'apparition des L4G (languages 4ième génération, qui proposaient en standard beaucoup de fonctionnalités) qu'on a commencé à faire (à tord) l'amalgame. En C++ on fait toujours bien la différence entre le C++ et la bibliothèque standard fournie plus ou moins exhautivement par tous les compilos (printf(), etc...).
Mais quand on developpe un driver ou une application embarquée, souvent, elle n'est pas disponible...
[/blah-blahtage historique]

... donc ca donne un certain nombre de stations (j'estime a la louche le nombre a 2-15) reliees a un serveur par un LAN classique
..., le serveur serait une machine surtout destinee a la communication et au management des stations,...
..., car les parties se font a une dizaine de joueur maxi et le jeu est relativement simple.

Je préconise 2 à 10, voire 3 à 10 station sur le LAN...

, donc une interface ouverte serait souhaitable si je veux pas me faire pieger..

Problème de conception ? Je veux bien t'aider, dès que j'aurais compris la question :
Qu'entends tu par interface ouverte ?

Bon a ce niveau la, qui dit internet dit TCP/IP (la je crois pas trop me tromper),

On t'a aussi conseillé UDP, mais c'est plus utile pour des messages envoyés très fréquemment pour lesquels on s'autorise une probabilité de perte... Si c'est des messages très ponctuels (sauvegarde en fin de manche, etc...) tu dois pouvoir utiliser TCP. Je serais même pas vraiment étonné que tu puisse pas vraiment faire du SQL en UDP.

en tout cas, ma question principale a l'heure actuelle serait :

- vaut il mieux prog mon reseau via c++ pour avoir la meme plateform partout (jeu et reseau) ?
- serait il plus judicieux de prog le reseau en java, relativement plus simple je crois a ce niveau (d'autant plus que je suis moins noob en java ^_^) et faire une passerelle de communication avec c++ pour que les donnees du reseau soit communiquees au jeu et vice-versa ?

Houlà oui !! Pour plusieurs raisons :
- Tu galèrera autant je pense à interfacer C++ et Java qu'à programmer correctement tes sockets en C++.
- Tu ne résouds quasiment QUE le problème des sockets, si tu doit programmer ensuite SQL, ça revient quasiment au même d'utiliser une classe C++ que Java.
- Tu augmente de beaucoup la complexité en temps (un deuxième processus qui tourne, des temps d'accès au réseau plus long (Java n'est pas connu pour sa rapiditée)) et en espace (plus de mémoire occupée, mais c'est un moindre mal).
- Tu multiplie les dépendances (tout le monde n'a pas forcément la VM de la bonne version ou un javax à jour, je dis peut-être des conneries je connais pas bien Java).

ps: j'aimerai bien etendre mes competence de prog a c++ d'ou mon dilemne, mais si c'est trop complique a mettre en place, et que java peut faire l'affaire, je me replierai vers cette seconde solution.

Ca me parraît pas être une bonne soluce, donc cherche plutôt à te diversifier !! D'autre par C++, même s'il est plus complexe que Java au premier abord, n'est que son ainé. Plus frustre un peu, mais ça fait sa puissance !

pps: desole pour la longueur du post

Pas de pb...

[JolyLoic]

par contre par multicast tu entends quoi ? broadcast par IP, ou bien le nom d'une autre API ?

multicast est une chose du même type que broadcast, mais un peu moins porc, puisqu'au lieu que tous entendent, seuls ceux qui se sont inscrits au préalable entendent.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winsock/winsock/multicast_programming.asp

Maintenant, je ne connais pas vraiment directX, mais il y a effectivement probablement là des choses plus haut niveau.

[k'n1]

ok tachons de ne rien oublier ^_^

Hé le stagiaire qui se la ramène... ...Je rigole bien sûr, j'ai fait la même réflexion à l'époque (Y'a tout juste deux ans...).

ok pour le passage historique, merci de faire mon education

Je préconise 2 à 10, voire 3 à 10 station sur le LAN...

heu... pourquoi ? quel probleme au dessus de 10 stations ? vu le debit je pense que ca devrait se faire sans probleme, apres le seul probleme vient de l'achat de hub pour le client, mais bon ca c'est son probleme

Problème de conception ? Je veux bien t'aider, dès que j'aurais compris la question :
Qu'entends tu par interface ouverte ?

Heu alors je dois fouiller me memoire... ha oui, je disais que le debit etait pas important donc je pouvais perdre de la bande passante sans trop m en soucier sur certains points, mais si je veux faire des developpement futur, il serait bon que justement je n'y aille pas a la gorer des le debut... ^_^

On t'a aussi conseillé UDP, mais c'est plus utile pour des messages envoyés très fréquemment pour lesquels on s'autorise une probabilité de perte... Si c'est des messages très ponctuels (sauvegarde en fin de manche, etc...) tu dois pouvoir utiliser TCP. Je serais même pas vraiment étonné que tu puisse pas vraiment faire du SQL en UDP.

autant pour moi, je voulais dire 'IP' et non 'TCP/IP' ... les messages sont effecitvement ponctuels, de l'ordre de la seconde, mais bon je prefererais eviter les pertes si possible... histoire de pas avoir a programmer un gros algo de reprise sur erreur et de premonition au niveau du moteur du jeu.

Houlà oui !! Pour plusieurs raisons :
- Tu galèrera autant je pense à interfacer C++ et Java qu'à programmer correctement tes sockets en C++.
- Tu ne résouds quasiment QUE le problème des sockets, si tu doit programmer ensuite SQL, ça revient quasiment au même d'utiliser une classe C++ que Java.
- Tu augmente de beaucoup la complexité en temps (un deuxième processus qui tourne, des temps d'accès au réseau plus long (Java n'est pas connu pour sa rapiditée)) et en espace (plus de mémoire occupée, mais c'est un moindre mal).
- Tu multiplie les dépendances (tout le monde n'a pas forcément la VM de la bonne version ou un javax à jour, je dis peut-être des conneries je connais pas bien Java).

L'interface java - c++ est relativement simple. je prog un bus CORBA auquel je connecte java, et mon collegue qui a prog le moteur du jeu fait la meme chose en c++ ... En java c'est ultra simple, en c++ je sais pas.
En ce qui concerne les process c'est pas faux, mais bon un prog qui fait juste du transfert de donnees par le reseau, sans trop de boulot a cote, ne devrait pas me devorer la memoire je pense...
Enfin, pour les dependances m'en fout ! : green: ... non en fait c'est que comme j'ai dit dans mon dernier message, serveur et stations sont installes par nous, donc repondent a nos specs (notamment, toutes tournent sous win2k je crois...)

Ca me parraît pas être une bonne soluce, donc cherche plutôt à te diversifier !! D'autre par C++, même s'il est plus complexe que Java au premier abord, n'est que son ainé. Plus frustre un peu, mais ça fait sa puissance !

oki c'etait un peu comme je le pensais ^_^

ok merci Loic pour les infos sur le multicast, ca m'a l'air sympa comme tout dans le principe... par contre, si je veux utiliser directx (ca me botte bien d'ailleurs, objectif principal comprendre comment tout ca fonctionne ces jours ci ^_^), il est clair qu il vaut mieux que j'evite de me melanger avec winsock, sinon ca va vite faire desordre... donc j'essairai de trouver l'equivalent en directplay (et ainsi limiter l'augmentation non lineaire du trafic en fonction du nb de stations dans le lan).

merci pour ces reponses, si vous avez d'autres idees / conseils / suggestions / 100 balles et un mars, n'hesitez pas a m'en faire part, tout peut m'aider ! et je vous paierai une biere si vous venez me rendre visite

edit : j'ajoute une question de noob win32 c++ (delphi et VB inside ^_^)... est il possible, avec .NET (ou un autre, preciser lequel) de voir les Forms sur lesquelles on bosse ? cad pouvoir placer son bouton en le deplacant avec la souris, le redimensionner, etc... parce que moi quand on me dit "Visual", basiquement j'espere quelque chose de ... visuel, quoi ! ^_^

[SKZ81]

Je préconise 2 à 10, voire 3 à 10 station sur le LAN...

heu... pourquoi ? quel probleme au dessus de 10 stations ? vu le debit je pense que ca devrait se faire sans probleme, apres le seul probleme vient de l'achat de hub pour le client, mais bon ca c'est son probleme

Y'a pas de problème, lis la citation (de toi) que j'ai faite. 10 joueurs max ????

Problème de conception ? Je veux bien t'aider, dès que j'aurais compris la question :
Qu'entends tu par interface ouverte ?

Heu alors je dois fouiller me memoire... ha oui, je disais que le debit etait pas important donc je pouvais perdre de la bande passante sans trop m en soucier sur certains points, mais si je veux faire des developpement futur, il serait bon que justement je n'y aille pas a la gorer des le debut... ^_^

Pas ce que j'appelle un problème de conception à proprement parler... J'appelle problème de conception le fait de s'interroger sur l'architecture de classes la plus à même de résoudre un problème de façon élégante (i.e. extensible).
Les problèmes de bandes passantes sont des contraites du "cahier à ta charge" (si je me souviens bien de ton expression)

autant pour moi, je voulais dire 'IP' et non 'TCP/IP' ... les messages sont effecitvement ponctuels, de l'ordre de la seconde, mais bon je prefererais eviter les pertes si possible... histoire de pas avoir a programmer un gros algo de reprise sur erreur et de premonition au niveau du moteur du jeu.

Mouarf ! Bon alors. Ponctuel n'est pas lié à la durée mais à la fréquence. Un échange ponctuel peut être long ou court, mais il n'est pas périodique (eventuellement, par abus de language, sa période est suffisemment longue pour que ça revienne au même). Mais autant pour moi, j'aurais du dire "sporadique".
De deux : tu veux bosser direct sur IP ? Ca me parraît ambicieux.
Si tu concède néanmoins à utiliser un protocole en surcouche, et que tu veux une garantie sur l'arrivée du paquet, utlise TCP.

L'interface java - c++ est relativement simple. je prog un bus CORBA auquel je connecte java, et mon collegue qui a prog le moteur du jeu fait la meme chose en c++ ... En java c'est ultra simple, en c++ je sais pas.

Simplicité d'écriture ne veut pas dire simplicité à l'éxécution... A part peut-être en assembleur (et encore!!)
CORBA dans mon souvenir, ce n'est pas la légèreté faite soft.
Ca me parraît un peu un turboréacteur pour mouvoir une poussette, ou plus précisément une pelle mécanique pour jouer au bille (l'expression usine à gaz ne veux plus rien dire et me fatigue...)
Mais bon, t'es au commandes de ton truc.

Et je vous paierai une biere si vous venez me rendre visite

Ca tu me le dira pas deux fois. Une seule ?
Dzol pour .NET contrairement à autre chose, je touche pas à ça

[k'n1]

Y'a pas de problème, lis la citation (de toi) que j'ai faite. 10 joueurs max ????

ha ok. Mais en fait c'est que le jeu est pas prevu pour des parties lan mais plutot des parties internet, et meme si partie lan il y a, le serveur devrait pouvoir en heberger plusieurs ^_^

Pas ce que j'appelle un problème de conception à proprement parler... J'appelle problème de conception le fait de s'interroger sur l'architecture de classes la plus à même de résoudre un problème de façon élégante (i.e. extensible).
Les problèmes de bandes passantes sont des contraites du "cahier à ta charge" (si je me souviens bien de ton expression)

lol c'est bien ca l'expression ^_^... oui effectivement j'appelle ca conception, on peut voir ca plutot comme un besoin que comme une option de conception... mais comme justement j'ai pas de cahier des charges precis, tout ca se melange et se module, pour faire une grosse "conception" ^_^

Mouarf ! Bon alors. Ponctuel n'est pas lié à la durée mais à la fréquence. Un échange ponctuel peut être long ou court, mais il n'est pas périodique (eventuellement, par abus de language, sa période est suffisemment longue pour que ça revienne au même). Mais autant pour moi, j'aurais du dire "sporadique".

Pas d'accord.
- frequence : periodicite, sporadicite (?)
- precision : ponctualite
- duree : brievete (?) , et peut etre ponctualite (du fait que ca vient de "point", mais comme j'ai pas de dico je peux pas etre affirmatif ^_^)

Bref, tout ca pour dire quoi, je sais plus, mais bon on est d'accord sur le cote sporadique. d'ailleur a ce propos, en admettant que j'ai un thread du programme principal sur le serveur LAN qui ecoute le buffer de mon communicateur, quelle frequence devrait je lui donner ? je pense comme ca a chaud a du "Frequence d'info du jeu en reseau * nb de clients connectes * 2" (le *2 par securite)..

De deux : tu veux bosser direct sur IP ? Ca me parraît ambicieux.
Si tu concède néanmoins à utiliser un protocole en surcouche, et que tu veux une garantie sur l'arrivée du paquet, utlise TCP.

ha non, pas du tout, pas fou quand meme ^_^ ... encore une erreur de ma part, quand j'entendais IP, je voulais dire un truc du genre *.*/IP (donc TCP ou UDP quoi...). et oui effectivement, je pense que TCP sera mieux..

Simplicité d'écriture ne veut pas dire simplicité à l'éxécution... A part peut-être en assembleur (et encore!!)
CORBA dans mon souvenir, ce n'est pas la légèreté faite soft.
Ca me parraît un peu un turboréacteur pour mouvoir une poussette, ou plus précisément une pelle mécanique pour jouer au bille (l'expression usine à gaz ne veux plus rien dire et me fatigue...)
Mais bon, t'es au commandes de ton truc.

oui je suis tout a fait d'accord, mais bon c'etait par simplicite de coding justement. Mais vu que je suis parti sur c++ directplay, je pense que ca c'est definitivement oublie... resultat de ma prog actuelle : un client, un serveur, ca se connecte, et la je tente de faire l'interface de communication entre ma classe et le programme principal, cote serveur, ce que j utiliserai ensuite ailleurs (tout ca avec un thread d'ecoute et une queue de messages), ce qui me permettre d'ataquer la partie communication ^_^

Ca tu me le dira pas deux fois. Une seule ?
Dzol pour .NET contrairement à autre chose, je touche pas à ça

ouaip pas de soucis, je t'attends ^_^

ok pour .NET, ca va j'ai un bon boss de .NET au bureau, il m'a fait un truc de fou furieux ce matin, je devrais m'en sortir.. et au pire je demanderai ici

merci de ton aide ^_^