LIBRAIRIE POUR SOCKETS C++
LeFauve42
Messages postés
239
Date d'inscription
vendredi 20 octobre 2006
Statut
Membre
Dernière intervention
20 avril 2009
-
31 mai 2010 à 11:27
rpoline Messages postés 1 Date d'inscription jeudi 23 septembre 2004 Statut Membre Dernière intervention 1 juin 2010 - 1 juin 2010 à 20:34
rpoline Messages postés 1 Date d'inscription jeudi 23 septembre 2004 Statut Membre Dernière intervention 1 juin 2010 - 1 juin 2010 à 20:34
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/51824-librairie-pour-sockets-c
https://codes-sources.commentcamarche.net/source/51824-librairie-pour-sockets-c
1 juin 2010 à 20:34
Typiquement dans ce genre d'application il vaut mieux écrire une fonction qui ré-assemble les données en provenance de la socket (si fragmentation) puis décoder la trame complète en provenance du Réseau avec une méthode dédiée.
J'ai pour ma part développer il y à quelques années développer une Solution Client/Serveur capable de gérer 600 connexions simultanées il nous a fallu 6 mois pour mettre au point le système.....
Richard
1 juin 2010 à 20:34
http://www.cppfrance.com/telecharger.aspx/?ID=51824
31 mai 2010 à 13:27
Dans une classe comme celle-ci, close(), bind(), listen(), accept() ne devrait pas être accessibles. A la limite j'aurais fait ça avec deux fonctions: read(unsigned), write(const Buffer&).
Au lieu de te prendre la tête avec les int8/16/32 tu peut envoyer n'importe que quoi (qui a son op<< sur ostream) en sérialisant via std::ostringstream.
31 mai 2010 à 13:05
31 mai 2010 à 11:27
Ca a l'air pas mal, mais je ne vois aucun mecanisme de bufferisation.
Envoyer des bytes ou des shorts un par un peu vraiment ralentir le trafic.
Il vaut mieux preparer un buffer de quelques Ko et faire un flush quand on veut tout envoyer (j'ai reussi a diviser mes temps de transmission par 10 grace a ce genre d'ameliorations).
C'est surtout efficace si l'un des deux hosts est tres vieux (dans mon cas, c'etait une communication avec un robot tournant sous Win98SE) mais ca doit quand meme aider avec des machines plus recentes.
Dans le meme genre, tes fonctions put_uintxx et get_uintxx sont tres inefficaces (faire 4 appels systemes pour ecrire 32 bits c'est (au moins) 3 de trop. Et je ne parle meme pas de tes fonctions pour lire une ligne ou un mot, qui lisent la socket caractere par caractere...
Pour faire simple, ton code est tres beau, mais du coup tres ineficace.
L'interet d'utiliser une lib avec des classes de haut niveau est aussi de pouvoir planquer dedans des trucs moins beaux mais efficaces (surtout pour des trucs de bas niveau comme les sockets).
Les gens qui utilisent la lib (si elle marche bien) ne regardent jamais dedans, alors autant faire un truc le plus efficace possible (tant que l'interface est jolie et pratique a utiliser).
Eric
NB: Si tu fais des tests de performance pour verifier ce que je te dis, utilise bien 2 machines, car sur le meme pc, les optimisations du loopback device (127.0.0.1) vont certainement masquer les defauts.
NB2: Si tu veux t'amuser a piloter un robot pour tester ta lib de sockets, on cherche des volontaires :o)