Déjà première chose : à mon sens tu te poses les bonnes questions, c'est bien !

recv est bloquant en effet, et c'est normal : cette fonction va récupérer les données qu'un autre programme lui envoie. Elle ne peut pas faire autrement qu'attendre d'avoir des données pour les restituer, elle est donc dépendante du bon vouloir de l'autre programme. Il s'agit d'une communication asynchrone.

Comme tu l'as donc remarqué tu auras besoin de dissocier l'écoute réseau de la gestion de l'interface. En réalité pour être tout à fait précis, tu as normalement au minimum 3 fils d'exécution : l'interface graphique, le calcul et les communications inter-processus. L'IHM est dépendante des actions de l'être humain et se doit d'être réactive (sinon l'interface se frise, phénomène bien connu des programmes java mal codés). En ce sens c'est assez proche de la problématique du réseau : l'humain envoie des données sous forme de clics, de touches frappées et ce de manière asynchrone.

Pour revenir à ta proposition, je t'arrête tout de suite quand tu veux faire un fork, et ce pour 3 raisons :

Premièrement ceci est lourd (comparé à du multithreading). Tu vas charger 2 fois ton programme, et une grande partie du code n'est pas utilisé dans les 2 instances, donc surcharge évidente de ton système (par rapport à du multithreading).

Deuxièmement tu auras à faire communiquer le père et le fils... Là tu as le choix entre les sockets, les flux (pipe) nommés, les sémaphores (purement signalétique et pour la synchronisation) ou la mémoire partagée (beaucoup d'emmerdes, et pas portables du tout du tout !!).

Troisièmement tu aurais intérêt à apprendre à faire du multithreading, notamment parce que c'est pas compliqué et parce que cela te feras toucher du doigts des aspects de synchronisation et de gestion des accès concurrentiels tout à fait primordiaux en informatique.


J'en viens à présent à un semblant de solution.
Je suis de nature trop ambitieuse quand je concois des solutions informatique. Mais ca n'est pas génant, on a toujours la possibilité de revenir à quelque chose de moins subtil et (souvent) de plus fiable à mettre en place.

Les communications réseaux sont asynchrones, cela veut dire que tu auras à gérer les communications entrantes au fil de l'eau. On peut voir une comm entrante comme un événement (des données associées à un traitement). Et là j'en reviens au protocole dont je t'ai parlé l'autre jour.
Tu auras donc un thread dédié à l'écoute sur la socket. Celui va boucler autour de la fonction read(). A chaque fois qu'il recoit un message, tu appelles une fonction de traitement de ce message. Tu peux imaginer qu'un code en début de message te permette de choisir la fonction à appeler (un switch fait l'affaire). Et voilà, c'est tout ! Tu as un système de communication événementiel. A toi ensuite de coder les fonctions pour que ton jeu tienne compte de ce qui arrive du réseau.

Un petit exemple est toujours utile :

Tu as développé un jeu de plateau, du genre bataille navale ou échecs.
Un joueur A fait un coup.
Ceci a des conséquences *locales* comme modifier les données de la partie et raffraichir l'IHM.
Et ceci a des conséquences *distantes* : le coup est transmis au joueur B.
B va donc recevoir par son module réseau un événement "A a tiré en C5" (pour la bataille navale ).
Cet événement va avoir des conséquences sur les données de la parties et sur l'IHM. On voit ici l'analogie entre l'IHM et le réseau.

Pour parler un peu en terme de conception, on est très vite tenté pour bien faire les choses de reprendre le modèle MVC (modèle, vue, controleur). Ce paradigme fait la distinction entre les données (le modèle), la vue (l'IHM) et le controleur (les boutons de l'IHM ou des événements comme ce que le réseau envoie).

M------V
\\ /
C------ Humain
\\------ Réseau

L'humain et le réseau vont déclencher des actions sur le contrôleur, qui va modifier le modèle en conséquence pour ensuite demander à la vue de mettre à jour avec la nouvelle version du modèle.

L'élément Réseau reste donc à construire. En résumé je te propose de retenir ceci:

• mettre en parallèle (dans un thread pour accéder à la meme zone de mémoire)
• faire une boucle d'écoute autour de read(), déclenchant du code à chaque réception d'un message
• coder les différentes fonctions associées à chaque message (ce code n'est pas très différent de celui qui est associé à l'interface graphique => mise en commun du code, plus robuste et plus facilement maintenable)

Voilà, encore une fois je n'ai pas pu m'empecher de faire long.
Si je n'ai pas été assez clair, n'hésite pas à intervenir à nouveau

sur ce, bonne nuit !
fred