Quelle classe STL pour un simple flux réseau ?

Bonjour,

Je développe une bibliothèque réseau portable qui doit permettre l'envoi d'objets. J'ai donc décidé d'utiliser les archives boost et d'envoyer le flux généré par les sockets Windows/Unix. J'aimerais un moyen simple d'y arriver, j'ai vu par exemple la classe stringstream, si je pouvais dériver de cette classe et simplement implémenter les opérations de lecture/écriture ce serait assez sympa (je ne vais pas réinventer le buffer).

Toutes les procédures de lecture/écriture sont implémentée, je dois simplement en faire un flux de type iostream sans avoir à réinventer la roue. J'aimerais n'utiliser que la STL, ou Boost (mon appli repose déja dessus).

Merci,

Fred

Salut !

La STL ou Boost n'intègrent pas (pour le moment) la gestion des Sockets.

Cependant, il y a une annexe de boost : Boost.Asio qui permet de gérer les sockets ;)

Merci de ta réponse,

Mais en réalité, j'ai déja rédigé toutes les procédures de communication, il ne me reste pour ainsi "plus qu'à" encapsuler ce code dans un objet iostream. Je suis en train de me renseigner, mais j'ai peur de devoir réécrire toute la gestion du buffer. Les opérations de lecture/écriture sont assez spéciales (envoi d'objets), et étant donné que j'ai déja écrit mes classes de communication, je n'ai pas besoin d'une nouvelle classe qui sera sans doute plus lourde et plus complexe à modifier.

Si vous aviez une solution qui me permette de proposer un objet iostream en n'implémentant que les fonctions qui permettent de remplir le buffer (recevoir) et vider le buffer (envoyer), ca me simplifierait bien la vie :)

Tu peux tenter une recherche sur streambuf, on a déjà donné quelques bons liens à ce sujet.

Sinon il me semble aussi que certaines bibliothèques qui font du socket utilisent cette méthode (ACE ?), tu pourrais t'en inspirer.

Je continue mes recherches, merci ;)

Et on commence par la :
http://groups.google.de/group/fr.com...rch+this+group
http://www.cmla.ens-cachan.fr/Utilis..._entree_sortie

Finalement, ces liens adressent plutôt le problème du contrôle de données plutôt que celui de l'écriture sur un nouveau média (ils utilisent une strcture FILE pour gérer leur buffer). Je suis en train de regarder socket++ pour m'inspirer de leur implémentation. Je me demande encore si strstream ne peut pas être dérivé simplement ...

Si tu veux ton stream à toi, alors tu devras dériver un streambuf. C'est ainsi.
Visiblement, tu as déjà trouvé la FAQ de fclc++.

J'avance tranquillement avec mes flux, j'ai donc dérivé std::streambuf, mais j'ai une petite question sur la fonction overflow. En effet, cette fonction prend un type "int_type" en entrée, probablement pour implémenter tous les caractères de contrôle comme EOF. Cependant, la fonction send ne prend en argument que des char* (sous VC8 int_type est un entier 64bits), j'aimerais savoir si le cast que j'opère est correct :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

virtual int_type overflow (int_type c) { int nsent;   if (c != EOF) { nsent = send(m_Socket, (char *)&c, 1, 0); if ( nsent != 1 ) { throw SocketIOException("Unable to send data", send_error, "SocketStreamBuffer::overflow", __FILE__, __LINE__); } }   return c; }

---

Une autre question, moins language celle là : sachant que je veux envoyer des petits objets serialisés, est-il judicieux d'utiliser un buffer ou peut-on utiliser un envoi synchrone (objet par objet, via xsputn) ?

moi, je dirais plutôt:

Code:

---

char c2 = (char)c; send(&c);

---

C'est sans doute la solution la plus pratique et la plus propre, je me demande pourquoi je n'y avais pas pensé :D. Merci !

La seconde question tient toujours : sachant que je veux envoyer des petits objets serialisés, est-il judicieux d'utiliser un buffer ou peut-on utiliser un envoi synchrone (objet par objet, via xsputn) ?

Et pendant que j'y suis, une petite interrogation sur le type int_type : Où est-il réellement défini ? Visual C++ le définit dans std::char_traits<char>::int_type, mais cette déclaration n'est sans doute pas portable. std::int_type n'existe pas, et int_type n'existe pas non plus dans le namespace global. Les fonction overflow et underflow utilisent ce type, en connaissez-vous une définition propre (je n'ai pas envie d'utiliser le namespace global) ?

Citation:

---

moi, je dirais plutôt:

Code:

---

char c2 = (char)c;

---

---

Inutile de caster ici.

Code:

---

char c2 = c;

---

fonctionne très bien et est plus sûr.

Citation:

---

Envoyé par loufoque

Inutile de caster ici.

Code:

---

char c2 = c;

---

fonctionne très bien et est plus sûr.

---

Ce code ne réalise-t-il pas déja un cast implicite ? Par quelle autre méthode le compilateur pourrait-il convertir ce type de base, et pourquoi est-ce plus sûr ?

Citation:

---

Envoyé par loufoque

Inutile de caster ici.

Code:

---

char c2 = c;

---

fonctionne très bien et est plus sûr.

---

Code:

---

warning C4244: 'initializing' : conversion from 'int' to 'char', possible loss of data

---

Quand Médinoc met un cast, c'est qu'il sert à quelque chose.
Par contre, je n'aurais pas dû mettre un cast C. un static_cast est plus approprié.

Merci Medinoc, je ne connaissais pas les cast statiques, ils me seront bien utiles ;)

Par contre, j'ai toujours un problème avec ces int_type qui sont définis n'importe où ... voici mon code :

SocketClasses.hpp

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

#include <streambuf> // SocketStreamBuffer base class   namespace SocketClasses { class SocketStreamBuffer : public std::streambuf { // ... protected: virtual int_type overflow (int_type c); virtual std::streamsize xsputn (const char *buf, std::streamsize len); } }

---

SocketClasses.cpp

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

#include "SocketClasses.hpp"   namespace SocketClasses { int_type SocketStreamBuffer::overflow (int_type c) { // ... }   std::streamsize SocketStreamBuffer::xsputn (const char *buf, std::streamsize len) { // ... } }

---

Et les erreurs de type qui s'en suivent :

Code:

---

1 2 3 4 5 6 7 8 9

------ Build started: Project: Socktest, Configuration: Test Win32 ------ Compiling... SocketClasses.cpp d:\alm\socktest\socktest\socketclasses.cpp(26) : error C2143: syntax error : missing ';' before 'SocketClasses::SocketStreamBuffer::overflow' d:\alm\socktest\socktest\socketclasses.cpp(26) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int d:\alm\socktest\socktest\socketclasses.cpp(27) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int Build log was saved at "file://d:\ALM\Socktest\Socktest\Test\BuildLog.htm" Socktest - 3 error(s), 0 warning(s) ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

---

G++ 3.4.4 me donne :

Code:

---

1 2	# g++ -ansi -Wall -pedantic -c SocketClasses.cpp SocketClasses.cpp:26: error: `int_type' does not name a type

---

Le type int_type est défini dans la classe mère std::basic_streambuf, je trouve curieux que je puisse utiliser ce type dans ma définition de classe (header) mais pas dans mon implémentation (cpp). Avez-vous une solution propre à ce problème ? Est-ce un bug du compilateur ? La seule solution que j'aie pour l'instant consiste à implémenter les fonctions dans le hpp, ou de déporter le traitement en inline dans d'autres fonctions qui ont des signatures à arguments courants et d'implémenter ces dernières fonctions dans le cpp. Mais très franchement, cette solution ne me satisfait pas du point de vue de la clarté du code.

Merci !

On n'est jamais mieux servi que par soi même : le remplacement de int_type par SocketStreamBuffer::int_type fonctionne, tout compile correctement ;)

Juste une question de fondamentaux : pourquoi les types définis dans la classe ne peuvent ils pas dans notre cas être utilisés directement dans les signatures de fonctions, alors qu'ils peuvent l'être dans la définition de la classe ?

Ne vous inquiétez pas, je mettrais le tag "résolu" lorsque j'aurais publié une première version qui fonctionne de mes classes ;)

Parce que dans la définition de la fonction, on est à l'extérieur de la déclaration de la classe. Il peut y avoir un type externe - oui, ça serait très sale - qui a le même nom, et ça reviendrait alors à une fonction surchargée :|

Merci Miles ;). Après réflexion ça parait logique, mais j’ai pensé que ces types seraient exportés et reconnus par les fonctions implémentées à l’extérieur de la classe.

Je suis presque au bout de mes peines, vous aurez bientôt mon code qui fonctionne ! Mais auparavant, j’ai toujours un drôle de warning avec VCC 8 :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

d:\alm\socktest\socktest\socketclasses.hpp(87) : warning C4996: 'std::basic_streambuf<_Elem,_Traits>::xsgetn' was declared deprecated with [ _Elem=char, _Traits=std::char_traits<char> ] c:\programme\microsoft visual studio 8\vc\include\streambuf(324) : see declaration of 'std::basic_streambuf<_Elem,_Traits>::xsgetn' with [ _Elem=char, _Traits=std::char_traits<char> ] Message: 'You have used a std:: construct that is not safe. See documentation on how to use the Safe Standard C++ Library' SocketClasses.cpp

---

Le ligne 87 est la suivante (dans ma classe SocketStreamBuffer) :
virtual std::streamsize xsgetn (char_type *buf, std::streamsize len);

Pour information, ce code compile parfaitement avec gcc, mais j’aimerais savoir s’il existe une autre façon d’implémenter les écritures de chaines sans buffer. Xsgetn est vraiment considéré comme obsolète ?

Le warning indique qu'il peut y avoir des problèmes de sécurité avec cette manière de faire, mais on peut supprimer ces warnings "non standards".
Pour trouver la fonction qui est plus adaptée avec ce compilo, regarde sur le site de la MSDN.
Pour comprendre le pourquoi de ces warnings : http://msdn2.microsoft.com/en-us/library/ms404581.aspx

C'est exactement ce que je cherchais, merci !

Donc sous Windows, on remplace :

Code:

---

1 2 3 4

virtual streamsize xsgetn( char_type *_Ptr, streamsize _Count );

---

Par :

Code:

---

1 2 3 4 5

virtual streamsize _Xsgetn_s( char_type *_Ptr, size_t _Ptr_size, streamsize _Count );

---

Par contre je ne saisis pas vraiment l'intérêt de cette nouvelle version ... j'ai juste modifié ma fonction xsgetn standard en ajoutant cette ligne, je ne sais pas si c'est vraiment judicieux :

Code:

---

1 2 3

#ifdef WIN32 len = min(len, count); #endif

---

En effet la doc Microsoft distingue longueur du tableau et nombre de caractères demandés. Dans mon esprit, on demandait assez de données pour remplir le tableau, si on en avait besoin de moins, il suffisait de réduire la taille 'len' du tableau en argument ...

Je vais commencer mes tests, dès que j'ai quelque chose de potable qui fonctionne, je poste.

L'objectif est de sécuriser au maximum les fonctions pour éviter des dépassement de mémoire, et autres. Pour une fois que Microsoft fait ce qu'il dit - ie promouvoir la sécurité - on leur tape dessus en disant qu'ils veulent faire leur propre standard :D

C'est bien entendu louable de déclarer des fonctions dangereuses et d'en promouvoir des versions sécurisées, cependant dans ce cas, je me demande ce que leur version apporte de plus. Je considère recevoir deux fois la même information : une longueur de tableau à remplir, et un nombre de caractères à fournir, je ne vois vraiment pas de grande différence (d'ailleurs je n'utilise qu'une valeur de longueur, le minimum des deux) : la longueur du tableau est normalement la taille à remplir. Mais si je me trompe corrigez moi ;)

Le deuxième paramètre est la taille du buffer, qui peut être différente de _Count. La méthode vérifie elle-même s'il y a assez de place dans le buffer.

Citation:

---

Envoyé par Miles

L'objectif est de sécuriser au maximum les fonctions pour éviter des dépassement de mémoire, et autres. Pour une fois que Microsoft fait ce qu'il dit - ie promouvoir la sécurité - on leur tape dessus en disant qu'ils veulent faire leur propre standard :D

---

Ils VEULENT faire leur propre standard. Sinon, ils auraient implémenté la fonction snprintf() du standard C99 au lieu de faire leur sprintf_s...
(sans parler de fopen_s qui ne sert absolument à rien, et de strtok_s qui est une pâle copie de strtok_r() avec un autre nom...)

Pour le standard C99, je ne dis pas, peut-être. En revanche pour le standard C++, basé sur le C89, ils ont raison d'aller plus loin, d'autant qu'ils ont des pointures dans l'équipe de développement de ce compilateur C++. Pour le C99, je ne sais pas pourquoi ils ne l'ont pas implémentée. De toute manière, VS2005 n'est pas un compilateur C99, mais encore C89, et ça se voit bien.

Bien, je crois que je suis arrivé à quelque chose de correct avec mes flux ! J'ai lu le chapitre correspondant dans Standard C++ IOStreams and Locales, vraiment un bon bouquin.

Voici mon code, je vous épargne les include et compagnie, pensez juste à inclure <streambuf> et <iostream>. Il manque aussi quelques opérateurs de portée globale, et j'ai un petit souci de protocole que je vous détaillerais plus bas. Cependant, cette solution de flux sans buffer est fonctionnelle :

Code:

---

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 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209

class SocketStreamBuffer : public std::streambuf { public: SocketStreamBuffer(SOCKET inSocket);   protected:   virtual int_type overflow (int_type c); virtual std::streamsize xsputn (const char_type *buf, std::streamsize len);   virtual int_type underflow (); virtual int_type uflow (); virtual int_type pbackfail (int_type c);   #ifdef WIN32 virtual std::streamsize _Xsgetn_s (char_type *buf, std::streamsize len, std::streamsize count); #else // UNIX virtual std::streamsize xsgetn (char_type *buf, std::streamsize len); #endif // WIN32   private: // The socket to read from / write to SOCKET m_Socket;   // One character buffer char_type m_charBuf; bool m_takeFromBuf;   // Sockets select variables fd_set m_socketSet; timeval m_zeroTimeOut;   // Prohitbit copying and assignment SocketStreamBuffer(const SocketStreamBuffer&); SocketStreamBuffer& operator = (const SocketStreamBuffer&); };   SocketStreamBuffer::SocketStreamBuffer(SOCKET inSocket) : m_Socket(inSocket), m_takeFromBuf(false) { FD_ZERO(&m_socketSet); FD_SET(m_Socket, &m_socketSet); m_zeroTimeOut.tv_sec = 0; m_zeroTimeOut.tv_usec = 0; }   SocketStreamBuffer::int_type SocketStreamBuffer::overflow (SocketStreamBuffer::int_type c) { int nsent;   if ( c != EOF ) { int blockState; SocketStreamBuffer::char_type tosend = static_cast<SocketStreamBuffer::char_type>(c);   nsent = send(m_Socket, &tosend, 1, 0);   if ( nsent != 1 ) { throw SocketIOException("Unable to send data", send_error, "SocketStreamBuffer::overflow", __FILE__, __LINE__); } }   return c; }   std::streamsize SocketStreamBuffer::xsputn (const SocketStreamBuffer::char_type *buf, std::streamsize len) { std::streamsize nsent;   nsent = send(m_Socket, buf, len, 0); if ( nsent != len ) { throw SocketIOException("Unable to send data", send_error, "SocketStreamBuffer::xsputn", __FILE__, __LINE__); }   return nsent; }   SocketStreamBuffer::int_type SocketStreamBuffer::underflow () {   if ( !m_takeFromBuf ) { int nread, blockState; SocketStreamBuffer::char_type car;   // Test if we should receive data blockState = select(0, &m_socketSet, NULL, NULL, &m_zeroTimeOut);   if ( blockState != 1 ) { // Nothing to read, return EOF m_charBuf = EOF; } else { // Read a new character and place it into the buffer nread = recv(m_Socket, &car, 1, 0); if ( nread == -1 ) { throw SocketIOException("Unable to receive data", receive_error, "SocketStreamBuffer::underflow", __FILE__, __LINE__); } else if ( nread == 0 ) { // Nothing to read, return EOF m_charBuf = EOF; } else { m_takeFromBuf = true; m_charBuf = static_cast<SocketStreamBuffer::int_type>(car); } } }   return m_charBuf; }   SocketStreamBuffer::int_type SocketStreamBuffer::uflow () {   if ( !m_takeFromBuf ) { int nread, blockState; SocketStreamBuffer::char_type car;   // Test if we should receive data blockState = select(0, &m_socketSet, NULL, NULL, &m_zeroTimeOut);   if ( blockState != 1 ) { // Nothing to read, return EOF m_charBuf = EOF; } else { // Read a new character and place it into the buffer nread = recv(m_Socket, &car, 1, 0); if ( nread == -1 ) { throw SocketIOException("Unable to receive data", receive_error, "SocketStreamBuffer::underflow", __FILE__, __LINE__); } else if ( nread == 0 ) { // Nothing to read, return EOF m_charBuf = EOF; } else { m_charBuf = static_cast<SocketStreamBuffer::int_type>(car); } } } else { // uflow steps forward m_takeFromBuf = false; }   return m_charBuf; }   SocketStreamBuffer::int_type SocketStreamBuffer::pbackfail (SocketStreamBuffer::int_type c) { if ( !m_takeFromBuf ) { // Put the character back in the buffer if ( c != EOF ) { m_charBuf = c; }   m_takeFromBuf = true; return m_charBuf; } else { return EOF; } }   #ifdef WIN32 std::streamsize SocketStreamBuffer::_Xsgetn_s (SocketStreamBuffer::char_type *buf, std::streamsize len, std::streamsize count) #else // UNIX std::streamsize SocketStreamBuffer::xsgetn (SocketStreamBuffer::char_type *buf, std::streamsize len) #endif // WIN32 { std::streamsize nread = 0; #ifdef WIN32 len = min(len, count); #endif   if (len > 0) { nread = recv(m_Socket, buf, len, 0); if ( nread == -1 ) { throw SocketIOException("Unable to receive data", receive_error, "SocketStreamBuffer::underflow", __FILE__, __LINE__); } }   return nread; }

---

Le problème avec cette solution est d'ordre technique : apparemment, les sockets TCP demandent d'avoir une socket en écoute avant de pouvoir envoyer des données, ce qui rend complexe la gestion des envois de rafales de caractères (beaucoup d'envois d'un seul caractère). Une solution avec buffer serait plus judicieuse, elle est en cours de développement :D, mais elle demande encore réflexion (quand faire un flush, le rendre implicite ou explicite, comment être sûr que le client écoute, ...).

Voilà, merci à tous, et j'espère que ce petit exemple vous sera utile !

Je ne suis pas un spécialiste, mais il me semble qu'il faut que tu redéfinisses la fonction sync() de streambuf pour y envoyer ton buffer ; apparemment elle est appelée par le flux à chaque flush (std::flush ou std::endl), ce qui me parait pas mal comme moment pour balancer la sauce sur tes sockets (à moins que tu ne veuilles faire un truc très performant, auquel cas effectivement il vaudra mieux que l'envoi soit contrôlé plus finement).

En réalité, cette fonction ne doit être surchargée que dans le cas d'un Streambuffer avec un réel buffer. Dans ce cas, il permet de remplir le buffer, mais dans mon cas très simple d'écriture synchrone, l'écriture est effectuée à chaque opération. Je suis cependant en train de me poser la question d'un buffer.

Attention, il se peut que le code ci dessus ne fonctionne pas comme prévu, j'ai des comportement étranges d'exceptions d'allocation dans les opérations de mon objet flux lorsque l'archive Boost s'initialise, je vous en dirais plus si j'arrive à comprendre ces problèmes.

Oui oui, ma réponse faisait bien suite à ta reflexion sur l'utilisation d'un buffer.

Pour les opérations avec buffer, il faut effectivement surcharger sync et gérer le buffer dans toutes les autres fonctions au lieu d'écrire directement. Reste à gérer en plus tous les problèmes de synchronisation ...

Il est à noter que l'exemple précédant ne fonctionne pas correctement lors d'une utilisation bidirectionnelle : instanciez deux objets, un pour l'écriture et l'autre pour la lecture ;)