problème socket et thread

problème socket et thread - C - Programmation

Marsh Posté le 09-03-2008 à 11:08:46    

Bonjour,
j'ai un serveur que j'aimerais bien tester sa charge.
pour cela j'ai développé un client qui implémente 250 thread. chaque thread devra envoyer des messages periodiquement selon une loi de poisson sur une socket qu'il ouvre en TCP avec le serveur.
Coté serveur, j'implémente un select qui traite toute les connexion entrante. Tout les envoie sont fait en mode TCP.
tous les messages qu'envoie mes thread sont des messages d'une taille inférieure à 1000 Octets.
 
En faisant des test j'ai remarqué que mon serveur génère quelques erreurs lors de la manipulation des messages recus. en débuggant j'ai remarqué que le la fonction recv recoit parfois des messages d'une taille de 1448 Octets ((j= recv(i, buf, sizeof(buf), 0)) = 1448)(dépassement de la Max SDU qui est de 1500 dans le cas d'ethernet) malgres que les messages que j'envoie sont toujours inférieur à 1000 Octets.
Svp, y a t'il quelqu'un qui a eu un pb pareil. Je ne sais pas si le problème viens de l'utilisation de socket paralèlle pour l'envoie avec plusieurs threads ou pas !!!!
De l'aide svp !!!!!

Reply

Marsh Posté le 09-03-2008 à 11:08:46   

Reply

Marsh Posté le 10-03-2008 à 17:39:08    

Citation :

recv recoit parfois des messages d'une taille de 1448 Octets ((j= recv(i, buf, sizeof(buf), 0)) = 1448)(dépassement de la Max SDU qui est de 1500 dans le cas d'ethernet

 

- TCP ne garantit pas la séparation des messages. Seul UDP le fait: raisonner sur une zone data max de 1500 octets est faux. Tu n'en sais rien, TCP peut envoyer deux trames ethernet de 1000 et 500 plutot qu'une seule de 1500, suivant l'état du flux et la congestion. Vois TCP comme une pipe(), qui balance un flux (alors que UDP envoie des messages, et non un flux ordonné et garanti).

 

- rien de choquant à ce que recv retourne 1448 octets pour TCP, suivant ce qui est mis en cache dans le noyau. Si tu n'as pas lu suffisamment rapidement tes premiers 1000 octets et que les deuxièmes arrivent, tu auras 2000 octets à lire en tout dans le buffer, jusqu'a ce qu'il y ait congestion (et là, le noyau arrêtera de retourner les ACK et droppera manu militari les paquets).

 

- Si tu veux garantir que pour tes deux bouts, tu puisses garder la séparation des messages, fais toi une fonction nread(), qui lira 1000 octets, et pas plus, pas moins (tu lis 1000, tu retranches la quantité lue, et tu relis, jusqu'a ce que le total fasse 1000).


Message édité par Gf4x3443 le 10-03-2008 à 17:40:40
Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed