threads simultanes sur une meme socket

**khayyam90** · 26/01/2006, 10h27

bien le bonjour,

je manipule une socket bloquante en lecture et en ecriture.
ne sachant pas trop si c'etait possible, je me suis lance dans l'heresie (?) suivante:
sur la meme socket, j'ai un thread qui lit et un autre qui ecrit. Donc le thread de lecture consiste en une boucle infinie d'attente tandis que le thread d'ecriture consiste juste en une suite d'envois.

c'est une socket sur laquelle je fais donc un dialogue avec un serveur. Il repond aux messages que j'envoie.

Et je me suis apercu que ca fonctionnait. Ma question est donc la suivante: est-ce dangereux d'utiliser 2 threads simultanes sur la meme socket ?
y a-t-il des precautions a prendre ?
dois-je verouiller la socket avec des mutex ? ou bien est-ce le systeme qui se charge d'eviter des acces au meme instant ?
Ou bien au contraire, est-ce une methode propre et massivement utilisee ?

**Aramis** · 26/01/2006, 11h38

Bonjour,

Je ne pense pas que cela soit un probleme. Le socket herite probablement du fonctionnement de l'interface sur laquelle il "tourne". Je m'explique. Les interfaces reseaux typiquement fonctionnent en Half-Duplex ou bien en Full Duplex. Dans le premier cas, l'interface ne peut faire qu'une chose a la fois c'est a dire recevoir ou envoyer. En Full-Duplex, les deux peuvent se passer en meme temps! Pourquoi serai ce un probleme au niveau de la couche applicative?

Par consequent, si votre interface fonctionne en Half-Duplex il est impossible que votre application est a Lire et Ecrire en meme temps. Voila comment je procede:

Code :

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

1
2
3
4
5
Application
*---ConnectionTCP
      *---Ecouter
      *---Envoyer

Ce qui donne en gros:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
public GenTCPClient&#40;string server, int port&#41;
	&#123;
		if &#40;port <= 0 || port >= 65535&#41;
		&#123;
			throw new ArgumentOutOfRangeException&#40;"Port number must be between 1 and 65535"&#41;;
		&#125;
		
		try
		&#123;
			this.serverName = server;
			this.port = port;
			client = new TcpClient&#40;server, port&#41;;
			connected = true;
		        send    = new ClientSend&#40;client&#41;;
			receive = new ClientReceive&#40;client, ServerDetails&#41;;
			receive.Start&#40;&#41;;
		&#125;
		catch &#40;Exception Ex&#41;
		&#123;
			connected = false;
			throw Ex;
		&#125;
	&#125;

Code :

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

1
2
3
4
5
6
7
8
internal ClientReceive&#40;TcpClient client, string serverName&#41;
	&#123;
		this.client = client;
		input = new StreamReader&#40;client.GetStream&#40;&#41;&#41;;
		this.serverName = serverName;
		thread = new Thread&#40;new ThreadStart&#40;Run&#41;&#41;;
	&#125;

Code :

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

1
2
3
4
5
6
internal ClientSend&#40;TcpClient client&#41;
	&#123;
		output = new StreamWriter&#40;client.GetStream&#40;&#41;&#41;;
		output.AutoFlush = true;
	&#125;

Comme vous l'avez probablement fait, je passe une reference aux differentes classes afin que le programme sache quel socket est a contacter.

Pour finir, tout ca ne marche que grace a l'unicite de la communication. Tout client ouvre un port au hazard et seul le port de destination (server) est connu. Par consequent, l'unicite de la communication est determine par l'adresse du client, le port utilise, l'adresse du server et le port de destination. Avec tout ca, il est clair qu'un probleme d'acces simultane ne peut etre que tres rare.

Tous ces chercheurs qui ont mis au point les protocols de communication reseaux ont bien fait leur boulot je trouve

Bonne continuation,

Ar@mi$

**khayyam90** · 27/01/2006, 06h53

merci pour ta reponse Aramis, j'ai bien aime le code pour l'illustrer

une petite precision,

Envoyé par tu

Les interfaces reseaux typiquement fonctionnent en Half-Duplex ou bien en Full Duplex.

le caractere half ou full duplex de l'interface depend-il d'un composant logiciel mis en oeuvre par le systeme ou bien est-ce inscrit dans les composants de la carte reseau ?

Et pour ma culture personnelle, y a-t-il moyen de changer le full duplex en half (et inversement) d'une interface reseau d'une maniere ou d'une autre ?

**Aramis** · 27/01/2006, 11h52

Re,

Envoyé par khayyam90

le caractere half ou full duplex de l'interface depend-il d'un composant logiciel mis en oeuvre par le systeme ou bien est-ce inscrit dans les composants de la carte reseau ?

"Inscrit dans le composant" est un peu fort mais il est vrai que cette caracteristique vient de la second couche du model OSI (e.g. data link) et donc souvent associe au propriete "physique" de l'interface.

Envoyé par khayyam90

Et pour ma culture personnelle, y a-t-il moyen de changer le full duplex en half (et inversement) d'une interface reseau d'une maniere ou d'une autre ?

Oui, il est possible de changer le mode de communication de l'interface. D'ailleurs la plus part des cartes reseaux par exemple supportent plusieurs vitesses et plusieurs mode communication. Le protocol "Handshake" utilise a ce niveau veut que les interfaces essayent les possibilites suivantes:

100 Mbps Full Duplex
100 Mbps Half Duplex
10Mbps Full Duplex
10Mbps Hald Duplex

Mais pourquoi "les interfaces" et non l'interface? Fondamentalement, un reseau est consitute d'un infinite de communications point a point et "Duplex" (Half/Full) definit les proprietes de cette communication (cf. mon poste precedent). Normalement, les interfaces sont en automatique pour ce genre de chose et c'est la machine la plus faible qui dicte la vitesse et mode de communication.

Je sens arriver la question: Peut on changer le mode par programmation? La reponse est oui! Par contre je ne pense pas que cela soit particulierement evidement. Qui plus est il faut que l'equipement auquel interface reprogramme est connectee le permette!

Ar@mi$ network astronaute

**khayyam90** · 27/01/2006, 12h35

Re,

et dans la serie 'pour la culture personnelle', dans le cas d'une utilisation half-duplex, quel est le comportement du systeme lors d'une lecture et ecriture simultanees via 2 threads. Disons par exemple que la lecture debute mais prend du temps et pendant ce temps, un autre thread tente d'ecrire.

Y a-t-il une mise en attente de l'instruction d'ecriture, une erreur ? Est-ce un comportement indefini ? La reaction est-elle normalisee ?

**ced2004** · 27/01/2006, 14h04

Bonjour
je reviens sur le début du sujet.
On utilise la socket avec lecture bloquante pour établir une conversation client serveur synchrone.
Donc le client envoie une requête et passe sur l instruction de lecture (bloquante), le serveur répond.
Par exemple :
le client envoie le message « heure »
Le serveur en attende sur la lecture capte le message, analyse la requête et répond (12:00) au client.
Le client doit aussi être capable d’interpréter la réponse si la communication permet plusieurs types requêtes.

Donc dans se type de client-serveur les threads du coté client ne sont pas indispensable mais comme l’a dit Aramis la manière que vous utilisez ne cause pas de problème.
Pour moi ce n’est pas une méthode massivement utilisé.
Dans ce type de conversation les threads sont utilisé du coté serveur pour pouvoir créer un serveur multi-connexion

Sinon du coté client les threads sont utilisé dans le cas d’utilisation de plusieurs sockets comme par exemple dans un client FTP.
Cela permet d'évite qu’une lecture sur une socket bloque l’écriture sur l’autre.

**khayyam90** · 27/01/2006, 14h13

ma conversation entre le client est le serveur n'est pas tout a fait sur le mode question reponse.

le client envoie des requetes au serveur et attend ses reponses, mais le serveur peut aussi a tout instant envoyer des donnees au client, c'est la raison pour laquelle j'utilise un thread permanent de lecture du cote de mon client. (je n'ai droit qu'a une seule socket)

**Aramis** · 28/01/2006, 13h10

Envoyé par khayyam90

[...]
dans le cas d'une utilisation half-duplex, quel est le comportement du systeme lors d'une lecture et ecriture simultanees via 2 threads. Disons par exemple que la lecture debute mais prend du temps et pendant ce temps, un autre thread tente d'ecrire.

Y a-t-il une mise en attente de l'instruction d'ecriture, une erreur ? Est-ce un comportement indefini ? La reaction est-elle normalisee ?

Par la nature meme du mode half-duplex, cela n'arrivera jamais. Le "stack" de l'interface reseaux, mettra les donnes a envoyer/recevoir dans une zone tampon en attendant qu'il soit physiquement possible de proceder a l'action suivante. Vu comme les protocols reseaux sont utilises je dirais sans hesitations que ces comportement sont normalises. Apres tout la plus part des developpeurs commencent a coder a partir de la couche 3/4 (adressage/transport) et par consequent leur code herite des proprietes des couches inferieures. khayyam90. vous devez bien realiser que votre application va fonctionner sur une variete d'interfaces (filaires, sans fils ...). Si vous deviez vous souciez de toutes les possibilites ou bien permutations, vous n'en finirez jamais. Les protocols sont la pour vous aider

Ar@mi$

**Aramis** · 28/01/2006, 13h21

Envoyé par khayyam90

ma conversation entre le client est le serveur n'est pas tout a fait sur le mode question reponse.

le client envoie des requetes au serveur et attend ses reponses, mais le serveur peut aussi a tout instant envoyer des donnees au client, c'est la raison pour laquelle j'utilise un thread permanent de lecture du cote de mon client. (je n'ai droit qu'a une seule socket)

Depuis le debut du sujet vous avez precisez que votre socket etait tout le temps a lecoute mais que l'envoie etait ponctuel. Dans mon experience a moi tout seul que je partage avec moi meme, j'estime que c'est LA chose a faire dans 90% des applications client/server et du coup vous avez eviter pas mal de problemes. Qui plus est, du point de vue des developpeurs cette histoire d'envoi de la part du client ou du server a avoir avec l'application c'est a dire la tache a remplir alors que les autres taches du protocol (par exemple TCP: synchro, taille de la fenetres et etc) se font en transparence totale!

Ar@mi$