Discussion :

[Nemesis007]

Je viens de me rendre compte que je vous ai uploadé le mauvais programme (Plusieurs de mes programmes porte le nom de "test" ...)

[goomazio]

Voilà une partie du code du serveur, qui est en C

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
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
 
 
memset((char*) &remoteAddress, 0x0, sizeof(struct sockaddr_in));
remoteAddress.sin_family = AF_INET;
remoteAddress.sin_port = htons(DEFAULT_PORT);
 
globale.listen_socket = socket (AF_INET, SOCK_STREAM, 0);
if(globale.listen_socket < 0)
{
	printf("socket() failed with code %d \n", globale.listen_socket);
	return 0;
}
sock_rc = bind(globale.listen_socket, (struct sockaddr*) &remoteAddress, sizeof(remoteAddress));
if(sock_rc != 0)
{
	printf("bind () failed with code %d\n", sock_rc);
	return 0;
}
sock_rc = listen(globale.listen_socket, 5);
if(sock_rc < 0)
{
	printf("listen() failed with code %d\n", sock_rc);
	return 0;
}
 
while(continuer)
{
        // on aloue de la mémoire (partagée? je ne sais plus) avec memset()
	memset((char*) &remoteAddress, 0x0, sizeof(struct sockaddr));
	remoteAddressLength = sizeof(remoteAddress);
	// on écoute les demandes de connexions
	server_socket = accept(globale.listen_socket, (struct sockaddr*) &remoteAddress, &remoteAddressLength);
	if(server_socket < 0)
	{
		printf("accept() failed with code %d\n", server_socket);
		return 0;
	}
	else
	{			
	        // quand un client se connecte, on démarre le thread qui va s'occuper de le gérer
		globale.client[globale.nombre_client].socket = server_socket; // garde le socket en mémoire pour que le serveur puisse fermer la connexion de tous les clients connectés
		if(pthread_create(&tid[globale.nombre_client], NULL, TraitementConnexion, (void*)(globale.nombre_client)) == 1)
		{
			printf("Erreur lors de la creation du thread\n");
			return 0;
		}
		globale.nombre_client++;
	}	
}

Je t'ai mis l'essentiel pour réceptionner les connexions, je ne me souviens plus très bien à quoi servent ces lignes là

Code :

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

1
2
3
memset((char*) &remoteAddress, 0x0, sizeof(struct sockaddr_in));
remoteAddress.sin_family = AF_INET;
remoteAddress.sin_port = htons(DEFAULT_PORT);

c'est des paramètres utiles...

Salut

[Nemesis007]

Je t'ai mis l'essentiel pour réceptionner les connexions, je ne me souviens plus très bien à quoi servent ces lignes là

Code :

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

1
2
3
memset((char*) &remoteAddress, 0x0, sizeof(struct sockaddr_in));
remoteAddress.sin_family = AF_INET;
remoteAddress.sin_port = htons(DEFAULT_PORT);

c'est des paramètres utiles...

Salut

Les lignes ci-dessus servent à configurer le port tcp mais hélas ne me serviront à rien vu que la communication se fait par rs232 mais c'est pas grave j'apprécie ton aide

[nicroman]

J'avoue n'avoir jamais travaillé sur un projet complexe. J'ai utilisé les threads pour une application de messagerie instantanée, et là à chaque fois qu'un client se connectait au serveur, le serveur créait un thread pour gérer ce client. L'utilisation d'un thread pour chaque client se justifie dans ce cas là.

Oui, l'utilisation d'un thread se justifie, mais en général un serveur ne "crée" jamais de thread quand un client se connecte.
Il crée un pool de threads au démarrage (50, 60...).
Quand un client arrive, il passe la main au premier thread libre (et lui signale de se réveiller). La création d'un thread est TRES couteux quelque soit l'OS: mise en place d'une pile, gestion des thread-local (ce qui implique passer a travers toutes les DLLs), ...

Dans le cas présent, il sagit d'allumer ou d'éteindre un bouton. Donc une action à priori tres rapide à décoder. Après tout dépend de la machine cible. Sur un Core2Duo, si le client doit attendre la connection un poil, c'est pas très grave, ca se jouera a une poignée de micro-secondes. En plus c'est du RS232, donc un seul client à l'autre bout... et je suis presque sur qu'il faut plus de temps à faire passer les données sur la RS232 qu'à les traiter

[goomazio]

En plus c'est du RS232, donc un seul client à l'autre bout

Je proposais un thread pour chaque message.

Vu ce que tu as dis, il est donc vraiment absurde de mettre en place tout un système de thread pour allumer ou éteindre la loupiotte
Alors donc le mieu, ne serait-ce pas de réceptionner les message d'une manière bloquante?

[Nemesis007]

En plus c'est du RS232, donc un seul client à l'autre bout... et je suis presque sur qu'il faut plus de temps à faire passer les données sur la RS232 qu'à les traiter

Oui entièrement d'accord avec toi, de toute façon si je ne reçois pas des trames je ne pourrai pas les traiter donc autant prendre du temps pour les recevoir.

Sinon, je fais le point sur ce que j'ai compris :

Mon programme est le thread principal. Dans ce dernier, j'aurai un thread qui me permet, dès que le serveur se connecte à mon client (je suis le client dans ce cas vu que je suis l'esclave), de recevoir la trame. Mais maintenant, je me pose une question, vaut mieux t-il pas de créer un autre thread dans le thread crée quand le serveur se connecte pour pouvoir analyser la trame, comme ca, je n'aurai pas de problème si je reçois plusieurs trames ?

Enfin une autre question, est ce que je dois crée un thread quand j'ouvre ma liaison RS232 ou dès le début de mon programme et dans celui-ci, j'ouvre la liaison ?

J'espère que je suis clair dans mes questions, si il y a un problème de compréhension n'hésitez surtout pas à me demander d'autres informations !




MERCI ENCORE POUR VOTRE AIDE

[goomazio]

Sinon, je fais le point sur ce que j'ai compris :

Mon programme est le thread principal. Dans ce dernier, j'aurai un thread qui me permet, dès que le serveur se connecte à mon client (je suis le client dans ce cas vu que je suis l'esclave), de recevoir la trame.

Pour faire cela un seul thread suffit, donc il ne faut pas créer de thread, le thread principal comme on l'a appelé pourra se charger de recevoir la trame. Du moins avec les sockets (code posté plus haut) c'est ainsi.

Mais maintenant, je me pose une question, vaut mieux t-il pas de créer un autre thread dans le thread crée quand le serveur se connecte pour pouvoir analyser la trame, comme ca, je n'aurai pas de problème si je reçois plusieurs trames ?

C'est de celà que l'on parlait plus haut, le problème c'est que l'analyse d'une trame est rapide et ne demande pas beaucoup de ressources. Comme dit plus haut, la gestion de threads n'est pas une chose si simple, un thread consomme des ressources et demande un peu de temps à se créer, s'initialiser... Et donc utiliser un thread pour analyser chaque trame, c'est comme si on devait transporter la petite voiture de bébé (un petit cuistax) sur un camion de 10 tonnes qui sert à transporter les nouvelles voitures chez un concessionnaire.

J'ai parlé de lecture bloquante, mais je me suis peut-être trompé. Ce à quoi je pensais ressemble à ça :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
un client se connecte à notre programme // notre programme est le serveur
 
BOUCLE tant que le client est connecté
 
   on reçoit un message du client // il va falloir analyser ce message qui contient une trame à analyser
   on analyse le message / la trame et on change l état de la lampe
   // puis on repart au début de la boucle et on attend d autres messages / trames
   // si on reçoit un message pendant que le programme analyse une trame, je ne sais pas ce qu'il se passera... Il sera peut-être mis en attente automatiquement (lecture bloquante) ou bien sera perdu
   // comme l'analyse ne prends pas longtemps, il y a moins de risque que l'on reçoive un message pendant l'analyse
FIN BOUCLE

Enfin une autre question, est ce que je dois crée un thread quand j'ouvre ma liaison RS232 ou dès le début de mon programme et dans celui-ci, j'ouvre la liaison ?

Tu créeras le thread quand tu en auras besoin. Sur le code que j'ai noté plus haut par exemple, tu peux voir que je crée un thread quand un client se connecte au serveur. A ce moment là, la fonction renvoie l'identifiant du socket qui servira à communiquer avec le client, et donc quand on a cet identifiant de socket, on peut commencer à communiquer... C'est pour cela qu'on crée le thread juste après, parceque, simplement, on commencera à échanger des messages avec le client. Et on avait dit que l'échange de messages entre un client et le serveur se ferait dans un autre thread pour que le thread principale puisse continuer à tourner (car sans thread on ne pourrait gérer qu'un seul client)

Code :

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

server_socket = accept(globale.listen_socket, (struct sockaddr*) &remoteAddress, &remoteAddressLength); // un client se connecte, on a le socket (server_socket), on n'a plus qu'a créer le thread qui communiquera avec le client