Discussion :

[Tymk]

Salut,

J'ai creer des classes C++ pour me simplifier l'utilisation des sockets : SOCKET_CLIENT et SOCKET_SERVER derivent de SOCKET_INIT. SOCKET_INIT contient notamment les fonctions d'envoi et de reception. Le code est prevu pour fonctionner en TCP et en UDP selon ce que l'utilisateur declare au constructeur.

Voici le code qui pose probleme :

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
bool SOCKET_INIT::recep()
{
	int num_byte;
	char buffer[MAXDATASIZE+1];
 
	/**** réception du message ****/
	if(get_type() == TCP){
		//reception TCP
		num_byte = recv(desc_new, buffer, sizeof(buffer)-1, 0);
	}else{
		//reception UDP
		socklen_t sin_size = sizeof(struct sockaddr_in);
		num_byte = recvfrom(desc_sock, buffer, sizeof(buffer)-1, 0, (struct sockaddr *) &dest_addr, &sin_size);
	}
 
	if(num_byte != 0){
		if(num_byte != SOCKET_ERROR){
 
			/**** traitement du message ****/
			buffer[num_byte] = 0; //ajout du caractère de fin de chaîne
			string addr = inet_ntoa(dest_addr.sin_addr);
			print_recep(addr, buffer);
			return true;
 
		}else{
			print_error("impossible de lire le message entrant");
			return false;
		}
	}else{
		print_info("client " + tostr(desc_new) + " déconnecté");
		return false;
	}
}

Cette fonction est commune au client et au serveur. Elle fonctionne parfaitement lors de son appel depuis le client(UDP), le serveur(UDP) et le serveur(TCP). Mais lors de l'appel depuis le client(TCP), elle n'attend pas l'arrivee du message et renvoie directement l'erreur "impossible de lire le message entrant" (bref, elle renvoie -1).

Y-a-il une precaution particuliere a prendre lors qu'on veut recevoir des donnees avec le client en mode connecte ?

Merci

[ram-0000]

Ton code semble correct.

Une question maintenant, le descripteur de ton socket est il membre de la classe SOCKET_INIT ?

J'ai l'impression qu'en TCP, il lit le socket "desc_new" qui je devine a un sens sur le serveur mais qui n'est pas initialisé sur le client (puisque c'est un client)

En UDP, il lit dans "desc_sock"

donc soit ta classe n'a pas de membre "socket" soit le membre n'est pas initialisé et dans tous les cas, tu semble lire dans le mauvais socket.

[Tymk]

Bien vu. "desc_new" n'a pas de sens sur le client et n'est donc pas initialise.

Mais ca m'ennuie de remplacer ma fonction SOCKET_INIT::recep() par SOCKET_CLIENT::recep() et SOCKET::recep() juste a cause d'une variable. D'un autre cote, je ne vois pas comment detecter si le socket est serveur ou client. A part en declarant un booleen au constructeur SOCKET_INIT(). Ce qui ne serais pas forcement plus elegant.

Un conseil ?

[ram-0000]

Je pense que tu as un petit problème de conception/architecture de tes classes.

Tu as un socket serveur SOCKET_SERVER qui dérive de SOCKET_INIT si tu veux pour lequel tu fais un bind(), listen() et accept(). Le send() et le recv() sur cette classe n'ont pas de sens

Tu as un socket client SOCKET_CLIENT qui dérive de SOCKET_INIT si tu veux pour lequel le send() et le recv() ont un sens. bind(), listen() et accept() n'ont pas de sens pour cette classe.

Ce socket client SOCKET_CLIENT peut être issu/créé par un connect() ou bien issu/créé du resultat du accept() mais dans les 2 cas, c'est un socket client. Maintenant, dans cette classe SOCKET_CLIENT tu peux créer/avoir besoin d'un flag qui indique si le socket est créé par connect() et donc explicitement par le programme ou bien si le socket est créé par un serveur et donc la conséquence du accept().

[Tymk]

Voici la "structure" de mes classes :

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
SOCKET_INIT{
     create_socket();
     adressage() = 0; //virtuelle pure
     send();
     recv();
};
 
SOCKET_SERVER : SOCKET_INIT{
     adressage(); //appel de bind()
     listen();
     accept();
};
 
SOCKET_CLIENT : SOCKET_INIT{
     adressage(); //appel de bind()
     connect();
};

SOCKET_INIT est sensee contenir tout ce qui est commun au client et au serveur. De cette maniere, j'obtiens un code "factorise".
C'est pour cette raison que send() et recv() sont dans SOCKET_INIT.

Mais, comme tu l'as mis en evidence, il semblerait que, en mode TCP, le recv()-serveur ne soit pas identique au recv()-client.

Je devrais donc declarer recv() virtuelle pure dans SOCKET_INIT et surcharger une version dans SOCKET_CLIENT et une autre dans SOCKET_SERVER.

Mais, comme je te disais, les 2 versions seront tres similaires et ca m'embette de dupliquer du code pour si peu.

Je doute qu'il y ait une meilleure solution mais si quelqu'un en a une, qu'il m'en fasse part.

PS: Je ne comprends pas pourquoi tu dis que send() et recv() n'ont pas de sens dans SOCKET_SERVER.

[ram-0000]

SOCKET_INIT est sensee contenir tout ce qui est commun au client et au serveur. De cette maniere, j'obtiens un code "factorise".

OK, c'est la base même

Mais, comme tu l'as mis en evidence, il semblerait que, en mode TCP, le recv()-serveur ne soit pas identique au recv()-client.

En mode TCP, le recv() et le send() sur un socket serveur (socket qui a fait bind(), listen() et accept()) n'ont pas de sens.

[Tymk]

hein ?!

Comment je fais pour envoyer/recevoir mes donnees depuis le serveur sans utiliser send() et recv() ?

[ram-0000]

Comment je fais pour envoyer/recevoir mes donnees depuis le serveur sans utiliser send() et recv() ?

Justement, c'est là que l'on ne se comprend pas.

sur un socket server, tu fais bind() puis listen() puis accept().

Le retour de ton accept() est un nouvel objet "socket client" créé par le noyau et ensuite le socket serveur retourne dans son listen()

Sur ce socket serveur, tu ne fais jamais send() et recv() (et d'ailleurs, cela ne marcherait pas)

Par contre, sur le socket issu du accept() donc créé par le serveur ou sur un socket créé par connect(), là, tu peux faire un send() et un recv().

Mais ne te trompe pas, ton socket créé par le socket serveur est un socket client.

[Tymk]

Ok, je comprends ce que tu veux dire.

Donc, mon erreur est bien d'avoir voulu appeler send() et recv() sur le desc_sock qui un socket serveur. Ca n'a effectivement pas de sens.

Cela signifie-t-il que la "structure" suivante serait plus correcte ?

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
SOCKET_INIT{
     create_socket();
     adressage() = 0; //virtuelle pure
};
 
SOCKET_CLIENT : SOCKET_INIT{
     adressage(); //appel de bind()
     connect();
     send();
     recv();
};
 
SOCKET_SERVER : SOCKET_INIT{
     adressage(); //appel de bind()
     listen();
     SOCKET_CLIENT sock = accept();
};

Etant donne que c'est pas super clair, je me permets de commenter :
J'ai voulu signifier par le "SOCKET_CLIENT sock = accept();" que je declarais une instance de SOCKET_CLIENT qui recuperais le descripteur retourne par accept();

Je pense que ce fonctionnement serais plus proche de la realite en TCP. Mais, UDP envoie directement des donnees depuis le socket serveur donc je devrais renoncer a faire une seule classe pour les 2 modes. Ca va certainement me frustrer pendant des semaines...

[ram-0000]

Pour moi, un socket TCP est conceptuellement différent d'un socket UDP.

• La notion de connecté/non connecté n'a pas de sens en UDP.
• La notion d'adresse IP et de port du remote n'a pas de sens en UDP (elle n'a de sens que sur le paquet reçu)

Donc oui, je partirai sur une classe différente entre TCP et UDP (héritant probablement d'un tronc commun)

Quelquechose comme cela :

Code :

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

1
2
3
4
5
6
7
8
 
TCP server-+
           !---------TCP socket-+
TCP client-+                    !
                                +--base socket
UDP server-+                    !
           !---------UDP socket-+
UDP client-+

(Pas facile de faire une arborescence avec la balise code )

La classe TCP serveur aurait une fonction bind()
La classe TCP client aurait une fonction send() et recv()

La classe UDP server aurait une fonction bind()
La classe UDP socket aurait une fonction send() et recv()

[Tymk]

J'ai bricole un truc et ca marche. Neanmoins, ton diagramme des classes a raisonner dans ma tete toute une nuit (j'exagere un peu).

Donc, je reprends en suivant ton diagramme qui est, soit dit en passant, tres reussi.

Pour TCP ok.

Pour UDP :

La classe UDP server aurait une fonction bind()
La classe UDP socket aurait une fonction send() et recv()

J'ai tendance a penser que la notion client-serveur en UDP est tres surfaite et limite inutile :
J'ai cree une classe SOCKET_UDP qui contient les fonctions d'adressage(), d'envoi() et de reception() et un descripteur de socket.
Et, je peux faire communiquer (envoyer/recevoir) 2 instances de cette classe. Il suffit d'adresser le "serveur" sur la machine locale et le "client" sur la machine distante.

J'ai fait le test dans le cas particulier ou la machine distante est egalement la machine local (loopback).

Mais un point reste obscur et c'est certainement la que se trouve la faille de mon raisonnement : Comment le serveur peut-il envoyer des donnees vers une adresse distante s'il est binde sur l'adresse locale ?

[ram-0000]

Neanmoins, ton diagramme des classes a raisonner dans ma tete toute une nuit.

Désolé

Pour UDP :
J'ai tendance a penser que la notion client-serveur en UDP est tres surfaite et limite inutile

Je suis presque d'accord avec toi dans le sens ou la notion de connexion n'a pas de sens en UDP. Après tout cela dépend de la "sensibilité" de chacun

Mais un point reste obscur et c'est certainement la que se trouve la faille de mon raisonnement : Comment le serveur peut-il envoyer des donnees vers une adresse distante s'il est binde sur l'adresse locale ?

En fait, c'est parce que le serveur "écoute" plus qu'il ne "bind" un port local. Il ecoute un port, recoit des données sur ce port et peut répondre à ces données. Tout cela viens du fait qu'il n'y a pas de connexion en UDP.

En TCP, il y a un "vrai" socket serveur et quand on se connecte à se socket serveur, le noyau créé un socket client issu du socket serveur qui est connecté au socket distant. Ceci n'a pas de sens en UDP.

J'espère que je me fais bien comprendre

[3DArchi]

Si je ne m'abuse, il doit y avoir un bind sur les deux extrémités du lien. Le bind sert à attacher un socket à une carte réseau donnée.
[UDP] Ensuite, le sendto et le recvfrom indique l'autre extrémité du lien. En UDP, tu risque d'avoir une implémentation de ton UDP-serveur et UDP-client identique... En fait, une seule classe CSocketUDP devrait suffire.

[ram-0000]

En UDP, tu risque d'avoir une implémentation de ton UDP-serveur et UDP-client identique... En fait, une seule classe CSocketUDP devrait suffire.

Je suis assez d'accord avec cette remarque, je vais donc moi aussi passer une mauvaise nuit.

[Tymk]

En fait, c'est parce que le serveur "écoute" plus qu'il ne "bind" un port local. Il ecoute un port, recoit des données sur ce port et peut répondre à ces données.

Ce que tu m'as dit sur le bind() m'a intrigue et j'ai fait quelques tests dont certains resultats m'echappent :

_ J'utilise les 2 memes instances de la classe SOCKET_UDP que j'avais utilisees dans mon message precedent
_ Je lance d'abord le serveur
_ Puis avec le client j'envoie le message "test"
_ Et je reponds "retest" depuis le serveur

-------- client ---------

INFO: socket 3 créé en mode UDP/IP
INFO: adressage defini
ERREUR: impossible de lier le socket à un point de communication
ip demandee: 127.0.0.1
ip obtenue: 127.0.1.1
port: 4212
test

------ serveur -------

INFO: socket 3 créé en mode UDP/IP
INFO: adressage defini
ip demandee:
ip obtenue: 127.0.1.1
port: 4212
127.0.0.1 > test
retest
127.0.0.1 > retest

Le message d'erreur indique que le bind() du client n'a pas reussi. Normal, le systeme a voulu attribuer la session que le serveur utilisait deja.
Le client envoie un message "test" qui est recu par le serveur. Par contre, le serveur recoit le message "retest" qu'il envoie. Normal, le serveur a un adressage sur l'adresse locale.

Dans le second essai, j'ai passe en argument au recvfrom() l'adresse utilisee lors de l'adressage initial. De sorte que, lorsque le serveur recoit un message, la fonction recvfrom() renseigne la structure sockaddr qui sera utilisee lors de l'appel de sendto(). Comme ca le serveur repond au dernier ip qui lui a envoye un paquet.

-------- client ---------

INFO: socket 3 créé en mode UDP/IP
INFO: adressage defini
ERREUR: impossible de lier le socket à un point de communication
ip demandee: 127.0.0.1
ip obtenue: 127.0.1.1
port: 4212
test
127.0.0.1 > retest

------ serveur -------

INFO: socket 3 créé en mode UDP/IP
INFO: adressage defini
ip demandee:
ip obtenue: 127.0.1.1
port: 4212
127.0.0.1 > test
retest

Il y a toujours le meme conflit au niveau du bind(). Mais cette fois le client recoit la reponse "retest" du serveur.

Comment le client peut-il recevoir un message alors que le bind() n'a pas ete effectue ?
Pourquoi, dans mon premier essai, seul le serveur a recu son propre message alors que, dans mon cas particulier (loopback), le client a exactement la meme adresse que le serveur (127.0.1.1) mais ce dernier n'a rien recu ?

[Tymk]

En UDP, tu risque d'avoir une implémentation de ton UDP-serveur et UDP-client identique... En fait, une seule classe CSocketUDP devrait suffire.

C'est effectivement ce que j'ai :

J'ai cree une classe SOCKET_UDP qui contient les fonctions d'adressage(), d'envoi() et de reception() et un descripteur de socket.
Et, je peux faire communiquer (envoyer/recevoir) 2 instances de cette classe. Il suffit d'adresser le "serveur" sur la machine locale et le "client" sur la machine distante.

[3DArchi]

Le conflit au niveau du bind doit être lié au fait que tu exécute le serveur et le client sur le même poste. A ce moment, il faut indiquer que tu veux pouvoir lier plusieurs socket sur les mêmes adresses/port. Utilise setsockopt avec SO_REUSEADDR sur tes sockets côté client et serveur.

[Tymk]

J'ai effectue le test sur un 2 postes differents et j'ai exactement les memes resultats que precedemment.

D'un autre cote j'ai reflechi un peu au bind. C'est sense lier le socket a une session port+ip du PC, non ?
Et, le serveur est adressee en local alors que le client l'est sur la machine distante.

Donc, quel est la fonction du bind() sur le client ? Lier un socket a un point de communication d'une machine distante ??? Ca n'a pas de sens !

Etes-vous sur qu'il est necessaire de faire un bind sur le client ?

[Médinoc]

À ma connaissance, il n'y a pas à faire de bind sur le client, à moins que quelque chose doive s'y connecter (exemple: P2P ou FTP actif)

[Tymk]

D'accord, mais, a priori si quelque chose s'y connecte c'est que ton client est en fait un serveur.

Donc, en realite, un bind sur un client n'a pas de sens.