Problème de sockets TCP

Recherche :

Mot : Pseudo : Filtrer
Bas de page
Auteur	Sujet : Problème de sockets TCP

Dumbledore

Bonjour à tous !

J'ai écrit un petit serveur (sous Linux) permettant la réception et l'envoi de messages sur le réseau. Cependant, lors de l'envoi de plusieurs messages d'affilé à un même client, tous les messages sont placés dans le même paquet TCP au lieu d'être placé dans des paquets différents. Ce problème ne se produit pas si je fais tourner le client et le serveur sur la même machine via l'interface de loopback ou si je mets une temporisation d'une seconde entre chaque messages.

J'ai écrit une fonction send_to permettant d'envoyer un message à un client et qui est appelée par les couches supérieures de l'application et une fonction wait_client, lancée dans un thread, qui est chargée d'initialiser la connexion avec un nouveau client et de stocker les messages entrant dans une file de réception.
Je gère la liste des clients via une liste chainée (liste_client_t est une structure correspondant à un maillon de cette liste)

A tout hasard, voici le code de la fonction d'envoi des messages et celui des fonctions de réception

Code :

void send_to(int sock,char *message){
pthread_mutex_lock(&mutex_sock);
if(send(sock,message,strlen(message),0) <1){
fprintf(stderr,"ERR : %s,%i : Envoi d'un message à %i (%s)\n",__FILE__,__LINE__,sock,message);
perror("send" );
pthread_mutex_unlock(&mutex_sock);
return;
}
sleep(1);
pthread_mutex_unlock(&mutex_sock);
}

Code :

static int sock_server // socket du serveur, déclarée en global
static int read_data(liste_clients_t *c){
int numbytes=0; // Nombre d'octets reçus
char buf[BUFFERSIZE]; // Buffer de réception des messages
if((numbytes=recv(c->c->socket, buf, BUFFERSIZE, 0)) <= 0) {
switch(numbytes){
case 0 :
fprintf(stderr,"ERR : %s:%i : Le client a coupé la connexion\n",__FILE__,__LINE__);
perror("recv" );
break;
default :
fprintf(stderr,"ERR : %s:%i : Erreur lors de la réception d'un message (erreur : %i)\n",__FILE__,__LINE__,numbytes);
perror("recv" );
}
return FALSE;
}
else{
buf[numbytes] = '\0';
pthread_mutex_lock(&mutex_file);
#ifdef DEBUG
fprintf(stderr,"DBG : %s:%i : Client : %i, %s : %s\n",__FILE__,__LINE__,c->c->socket,inet_ntoa(c->c->addr_client.sin_addr),buf);
#endif
// Ajout du message reçu dans la file d
if(!add_message(buf,c->c->socket)){
fprintf(stderr,"ERR : %s:%i : buffer d'entrée plein\n",__FILE__,__LINE__);
}
pthread_mutex_unlock(&mutex_file);
}
return TRUE;
}
/**
* Thread permettant de placer le serveur en attente de connexion
* */
static void *wait_client(){
int max_sock=0;
struct timeval wait_time;
int ret_select;
liste_clients_t *parcours,*temp;
// Liste des sockets pour select();
fd_set list_sock;
while(1){
wait_time.tv_sec = 0;
wait_time.tv_usec = 200;
// On bloque l'accès aux sockets
pthread_mutex_lock(&mutex_sock);
// Génération du fd_set pour select
build_select_list(&max_sock,&list_sock);
// On attends qu'un message arrive,
// select modifie list_sock en enlevant les sockets pour lesquelles il ne s'est rien passé
ret_select = select(FD_SETSIZE,&list_sock,NULL,NULL,&wait_time);
if(ret_select < 0){
perror("select" );
exit(EXIT_FAILURE);
}
if(FD_ISSET(sock_server,&list_sock)){
#ifdef DEBUG
fprintf(stderr,"DBG : %s:%i : Nouvelle connexion\n",__FILE__,__LINE__);
#endif
// On ajout le client à la liste des clients
new_connexion();
FD_CLR(sock_server,&list_sock);
}
else{
parcours = liste_clients;
while(parcours != NULL){
if(FD_ISSET(parcours->c->socket,&list_sock)){
#ifdef DEBUG
fprintf(stderr,"DBG : %s:%i : Message arrivé\n",__FILE__,__LINE__);
#endif
if(read_data(parcours)){
FD_CLR(parcours->c->socket,&list_sock);
parcours = parcours->next;
}
else{
temp = parcours;
parcours = parcours->next;
drop_client(temp);
}
}
else{
parcours = parcours->next;
}
}
}
pthread_mutex_unlock(&mutex_sock);
}
pthread_exit(NULL);
}

Voilà, je remercie d'avance ceux qui m'aideront à régler ce problème. Y a-t'il un appel système du même genre que fflush mais fonctionnant sur les sockets ?

Publicité

francky06l

Le fait d'avoir les messages dans les memes paquets c'est normal, ca fait partie du Nagle Algo (qui attend environ 200 ms avant d'envoyer ou cas ou d'autre donnees sont mise en queue pour le meme destinataire, cela evite les "petits paquets" et les collisions reseaux). Sur la meme machine en loopback, rien ne sort sur le reseau alors ca marche.
Tu peux "disabler" le Nagle, ou alors avant d'envoyer un autre message attendre un reponse du client.

Dumbledore

J'ai ajouté ça dans mon code pour le désactiver sur la socket du serveur et sur chaque socket des clients :

Code :

setsockopt(socket, IPPROTO_TCP, TCP_NODELAY,&disable_nagle, sizeof (disable_nagle));

avec disable_nagle = 1

Mais, ça ne fonctionne toujours pas.... :??:

Voici la fonction qui est lancée pour traiter les nouvelles connexions

Code :

static void new_connexion(){
int disable_nagle = 1;
// Stockage temporaire du numéro de socket d'un client
int socket_temp;
// Stockage temporaire de l'adresse IP du client
struct sockaddr_in addr_temp;
// Pour passer à la fonction accept()
int sin_size=sizeof(struct sockaddr_in);
if((socket_temp = accept(sock_server, (struct sockaddr *)&addr_temp,&sin_size)) < 0){
perror("accept" );
return;
}
client_t *temp = new_client(socket_temp,addr_temp);
add_new_client(temp); // Ajout du nouveau client dans la liste
setsockopt(socket_temp, IPPROTO_TCP, TCP_NODELAY,&disable_nagle, sizeof (disable_nagle));
printf("Nouveau client (%i) : %s\n",temp->socket,inet_ntoa(temp->addr_client.sin_addr));
}

Message édité par Dumbledore le 20-01-2006 à 11:11:21

francky06l

Une autre solution, serait de d'envoyer la taille du message avant le message. Le client pourrait ainsi "couper" au bon endroit. Tu envois un int avec la length, dans le client tu lis d'abord sizeof(int), ensuite le nombre de caracteres. Attention si tu "mixes" les plateform a l'Endian case.

Dumbledore

J'y avais pensé, mais techniquement, je ne peux pas mettre ta solution en oeuvre pour des raisons de compatibilité avec les clients....

En fait, ce qui se passe, c'est qu'il envoie un certain nombre de paquets correctement, puis ensuite, il les envoie n'importe comment alors que les données ont toutes la même taille

Message édité par Dumbledore le 20-01-2006 à 11:27:43

blackgoddess

vive le troll !

bin s'ils font tous la meme taille tu les découpent toi meme alors

il faut voir le tcp comme un flux, pas comme des paquets. c'est à toi de découper à l'arrivée.

---------------
-( BlackGoddess )-

Dumbledore

Ce que je veux dire, c'est que là, j'envoie d'affilé plusieurs messages de même taille lors de l'initialisation de la connexion avec les clients, mais après, en fonctionnement normal, les messages sont de longueur variable.

Y a un truc auquel je pensais : vu que tous nos messages sont divisés en champs dont on connait le nombre, ça serait de rajouter un nouveau champ ne contenant que du bourrage. Dans ce cas, quelle est la taille maximale de la charge d'un paquet TCP sur un réseau ethernet ? Les clients pourront faire le tri sans problème , mais le découpage, c'est pas viable

Exemple de ce que j'envoie et reçois (c'est pour un jeu et entre les différents groupes, tout doit être compatible):

MAP_START
MAP_SIZE:11
MAP_LINE:A A 0 0 0 2 2 0 3 B B
MAP_LINE:A A 0 0 0 0 0 0 0 B B
MAP_LINE:0 0 0 0 0 1 0 0 0 0 1
MAP_LINE:0 0 0 3 3 1 1 0 0 0 0
MAP_LINE:2 2 0 0 0 0 0 0 2 2 0
MAP_LINE:2 3 0 0 0 0 0 0 0 0 0
MAP_LINE:3 3 0 0 0 0 2 2 2 2 0
MAP_LINE:3 0 0 0 0 0 2 2 2 0 0
MAP_LINE:0 0 0 0 0 0 0 0 0 0 0
MAP_LINE:C C 0 0 0 0 0 0 0 D D
MAP_LINE:C C 0 0 0 0 0 0 0 D D
MAP_END

Tout ce qui se trouve entre 2 "recu : " correspond à un paquet TCP...

Recu : MAP_START
Recu : MAP_SIZE:11
MAP_LINE:A A 0 0 0 2 2 0 3 B B
MAP_LINE:A A 0 0 0 0 0 0 0 B B
MAP_LINE:0 0 0 0 0 1 0 0 0
Recu : 0 1
MAP_LINE:0 0 0 3 3 1 1 0 0 0 0
MAP_LINE:2 2 0 0 0 0 0 0 2 2 0
MAP_LINE:2 3 0 0 0 0 0 0 0 0 0
MA
Recu : P_LINE:3 3 0 0 0 0 2 2 2 2 0
MAP_LINE:3 0 0 0 0 0 2 2 2 0 0
MAP_LINE:0 0 0 0 0 0 0 0 0 0 0
MAP_LINE:
Recu : C C 0 0 0 0 0 0 0 D D
MAP_LINE:C C 0 0 0 0 0 0 0 D D
MAP_END

Message édité par Dumbledore le 20-01-2006 à 11:50:20

francky06l

La taille des paquets n'est pas toujours la meme (MTU / MSS). De plus dans le cas de WAN etc il peut y avoir des "points" (routeurs ...) qui "redecoupent..donc pas viable.
Par contre comme je disais avant, en envoyant la longeur avant le message normalement t'as pas de probleme, tu peux meme ajouter un calcul de crc pour verifier si tu veux.

Ce genre de schema simplifie

cote serveur :

int SndMyMessage(socket s, const char* mess)
{
int i = strlen(mess);

snd(s, &i, sizeof(int));
snd(s, mess, i);
}

cote client :

int RcvMyMess(socket s)
{
int i;
char buff[256];

rcv(s, &i, sizeof(int));
rcv(s, buff, i);
}

Dumbledore

Ouép, mais je peux pas modifier le code des clients...

Dumbledore

Désolé de faire un UP, mais personne n'a d'idée pour mon problème ? Je ne peux vraiment pas toucher au code des clients pour des raisons d'interropérabilité...

Le programme marche impec sur le loopback ou si le réseau n'est pas saturé. Le problème, c'est que ce ne sont pas des situations réelles de fonctionnement...

Publicité

moi23372

A vrai dire, si tu ne peux modifier les clients, ça va être dure. Les clients sont donc mal programmé depuis le début.

De plus la solution d'envoyer un int avant n'est absolument pas portable. Car sur certain réseau, le bit de poid fort est mis avant et parfois après. Ce genre de converssion est vraiment lourde au niveau de la programmation.
C'est vrai que cette solution est à mon avis la meilleure. Mais faut pas passer par un entier, mais par une chaine de caractère de longueur fixe. Les chaines de caractère ne sont pas soumis à ce problème de bit de poids fort/faible.

Voila moi perso je ne vois pas de solution, pour moi c'est donc un problème au niveau de tes clients. C'est à eux à découper les données correctement.
Si comme tu dis, les longueurs sont variables, les clients doivent bien découper quelque part le paquet reçu. Il faut qu'il le sache. Donc à mon avis, le problème qui se pose ici (qui n'en est pas un à mon avis) tu ne saurais le régler sans aller modifier le client qui va avec...

francky06l

Un int avant est une idee, pour la portabilite rien n'empeche d'envoyer sous format string de 4 bytes ("0124" ) et de faire un receive puis un atoi de cette chaine..
Mais bon si tu ne peux pas modifier les clients ... Peut etre mettre une tempo cote server, c'est a dire que tu attends par exemple 500 ms entre les messages pour le meme client. Dans ton server tu stockes l'heure d'evoie du dernier message et quand tu envois un nouveau tu verifies que l'ecart est bien "suffisant"..
Si les chaines que tu envois sont "null terminated", normalement le client detecte que le nombre de bytes recu est > strlen(chaine), donc il doit savoir qu'il y a une autre chaine... Si c'est des vrais "string" que tu envois, sois sur d'envoyer le '\0' final.

C'est un peu de bricolage, c'est vrai qu'un petit changement du soft client serait plus facile.

francky06l

Desole, en regardant le code que tu as poste avant .. Apparemment tu recois un maximum de BUFFERSIZE dans le client. La solution c'est que le server envois toujours BUFFERSIZE en longeur (tu completes la fin avec des '\0').. Je ne vois que ca sans modifier le client.

Dumbledore

j'vais voir ce que ça donne en bourrant avec des \0

FORUM HardWare.fr

Programmation

Problème de sockets TCP

Sujets relatifs
Probleme avec ma version JAVA ? j'arrive pas a faire tourner un prog ?	probleme avec include file
problème avec CreateGraphics()	[résolu][CSS] Probléme avec... FF !
[C] Problème de sockets	Probleme de switch
Problème d'accès temps réel	problème datagrid et index des columns
SQL : Gros problème de lenteur sur un UPDATE
Plus de sujets relatifs à : Problème de sockets TCP

Page générée en 0.088 secondes