Bonjour,
Un peu a chacun sa façon de prendre un programme... Personnellement je mettrais de côté la partie réseau pour m'attaquer au coeur du programme. Je ferais en premier la partie dédiée au serveur.
Ce que je viserais c'est une librairie, qui permet de gérer tout avec des protections contre le multi-thread. Après qu'il y ait un serveur qui la commande cela ne change plus rien.
Je ferais aussi un grand découpage !
- La partie métier pure, (définition d'un Enchérisseur, d'un Objet, d'une Enchère etc...) Et surtout définir une interface commune pour le client et le serveur.
- La partie serveur qui ouvre des connections pour des clients et interroge la partie métier pour renvoyer une réponse. (Un Socket d'où un thread par client)
- La partie client qui interroge le serveur.
Plus en détails je ferais
- la gestions complète du système d'enchère en définissant une interface. (1 projet librairie)
- Un serveur qui écoute, découpe les messages et utilise cette interface. (1 projet exécutable)
- Une couche client qui ré-implémente l'interface de la librairie pour rediriger les appels aux fonctions vers le réseau. (1 projet librairie)
- Un client qui utilise cette librairie. (1 projet exécutable)
L'avant dernier point impose une contrainte supplémentaire plutôt que de refaire une interface spécifique pour le client, on se force à prendre éxactement la même, mais cela permet de tester facilement le client sans la couche réseau, on branche directement sur la librairie supposée distante, juste en changeant ce petit morceau.
M.
"c:program filessony online entertainmentstation launcherstationlauncher. exe"
