Discussion :

[Invité]

Bonjour, j'étudie actuellement les sockets à l'iut, et pour prendre un peu d'avance je veux m'amuser à me faire une petite "API" de gestion de serveur/client.
Je m'explique, je veux faire des classe qui permettent de mettre en place un serveur/multi client facilement et rapidement pour l'utiliser pour faire des jeux type plateau/carte/dé.

En gros ce que je veux c'est un client/serveur qui communique sous forme de "requete (une abstraction des donnes via une classe)". Ce que j'ai pu apprendre pour l'instant c'est que le serveur accepte une connexion que j'ajoute dans une pool et je boucle sur la reception.
Idem pour le client je me connecte et met dans un thread une boucle pour la reception.

Maintenant, j'aimmerais pouvoir faire une methode qui fait une requete au serveur mais qui attend une reponse pour la retourner. Seulement mon probleme c'est comment attendre une réponse du serveur alors que mon autre thread coté client qui boucle pour la reception risque de l'intercepter avant. j'ai pensé à synchroniser sur mon InputStream mais je risque vite d'être en deadLock. Ou utiliser deux socket un pour la reception, et l'autre pour l'emission de requete avec retour.

[thelvin]

Euh... À moins que tu sois en asynchrone, ce qui pour débuter serait un peu costaud quand même,

pour le client tu n'as pas besoin d'un "autre thread." Un seul thread suffit. Ça ressemble à ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
try(Socket socket = creerMaSocket()) {
	InputStream in = socket.getInputStream();
	OutputStream out = socket.getOutputStream();
	while(jeNeVeuxPasArreter()) {
 
		envoyerUneRequete(out);
		ReponseDuServeur reponse = lireUneReponse(in);
		faireQuelqueChoseAvecLaReponse(reponse);
	}
}

[Invité]

Ouai je comprend, du coup j'ai fait un systeme où l'utilisateur creer un "requestPattern" où il doit surcharger une methode process qu'il ajoute à une classe "RequestProcessing" et cette classe ce charge de rediriger les donnee recu avec le bon process. enfin si vous avez le temps voici mon code : (Dites moi si j'ai fait une aberation )https://github.com/douney/MyServer

[thelvin]

aberration pas forcément, ça dépend pourquoi tu as fait comme ça.
Mais :
- c'est énormément plus compliqué que ce que j'ai dit,
- ça n'a pas l'air plus puissant que ce que j'ai dit

Donc a priori comme ça, c'est pas convainquant.
Pourquoi avoir séparé émission et réception dans deux endroits différents et deux threads ? Le serveur peut décider de sa propre initiative d'envoyer des informations sans avoir reçu de requête ?

[Invité]

Oui, le serveur peut dans le cadre d'un tchat envoyer des donnees sans avoir recu de requette préalable, et comme je fait ce petit projet pour la suite coder différent jeu de carte / plateau et je pense (mais rien n'est encore décidé) que le serveur va gérer le jeu en envoyant une requette de permission de jouer à tour de role, pour ca que je sépare emission et reception et pour la complication je trouve que c'est assez simple a utiliser après je défini le role de mes requetes et j'ai plus qu'à communiquer.

[thelvin]

Dans ce cas c'est bien, il aurait juste fallu le dire dès le début.

Attention côté serveur : il faudrait pas qu'il mélange l'envoi d'une réponse et l'envoi d'un message de sa propre initiative. 'Faut synchroniser l'accès à la socket pour toute la durée d'un envoi, je sais pas si tu le fais.

[Invité]

Ha en effet, une question par rapport à ça, si j'utilise un flux bufferisé, sans synchroniser je ne devrais pas avoir de problèmes (en TCP) ?

[thelvin]

Ça dépend ce que tu appelles bufferisé.
Il est vrai que l'InputStream de la socket synchronise les appels à write(), ce qui fait que si tu fais un seul appel pour un envoi de message, les envois de messages ne peuvent pas se mélanger.

Mais si tu utilises simplement un BufferedOutputStream ça ne change rien : d'abord il faut en utiliser un seul par Socket, donc dans les deux cas tu utilises le même donc ça ne change rien, et ensuite lorsque le buffeur est plein il va l'écrire dans la socket, et donc ça fait autre chose que un appel par envoi de message.

[Invité]

Dacodac, merci pour les précisions