Discussion :

[poukill]

Bonjour à tous,

Je me pose quelques questions quant au choix technique pour l'envoi et la réception de donnée client/serveur sur un réseau Internet, que ce soit en synchrone ou asynchrone.
Dans le tuto de khayyam, le choix est porté sur une sérialisation et un envoi "brute" de données sur le réseau.

Code :

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

1
2
3
4
5
6
7
8
void network_machine::TCP_send(engine_event& e){
	std::ostringstream archive_stream;
	boost::archive::text_oarchive archive(archive_stream);
	archive << e;
	const std::string &outbound_data = archive_stream.str();
 
	s_tcp->send(asio::buffer(outbound_data));
}

Avec la fonction receive associée:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
void network_machine::TCP_async_receive(const asio::error_code& e, size_t bytes_received){
	// let's deserialize the message
	std::string str_data(&network_buffer[0], network_buffer.size());
	std::istringstream archive_stream(str_data);
	boost::archive::text_iarchive archive(archive_stream);
 
	engine_event ne;
	archive >> ne;
 
	// add the event to the received event queue
	parent->push_received_event(ne);
}

Celà pose plusieurs problèmes pour moi. Quelle doit être la taille du buffer pour la réception? Est-on sur de récupérer toutes les données?

Dans un autre style, l'exemple du chat de boost choisit d'avoir un header avec la taille du message à envoyer...

Code :

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

1
2
3
4
5
6
7
8
 
class chat_message
{
public:
  enum { header_length = 4 };
  enum { max_body_length = 512 };
   //....
};

Code :

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

1
2
3
4
5
6
7
8
// Réception : lecture du header
boost::asio::async_read(socket_,
        boost::asio::buffer(read_msg_.data(), chat_message::header_length),
        boost::bind(
          &chat_session::handle_read_header, shared_from_this(),
          boost::asio::placeholders::error));
// puis réception du reste...
// .........

Là il faut avouer que c'est nickel. Par contre, tout est fixé à l'avance. Ca laisse peu de place à des messages sérialisés beaucoup plus compliqués possédant des std::map, std::string, std::vector et autres conteneurs dont on ne peut prédire la taille... (on peut tout de même calculer la taille des données, mais contrairement à l'exemple de boost, tout ne serait pas réglé à la compilation)

En conclusion, faut-il systématiquement envoyer la taille des données que l'on va transmettre suivant un protocole bien établi entre le client et le serveur, ou bien l'envoi plus "freestyle" convient aussi bien dans certains cas?

Merci pour vos éclaircissements...

[ram-0000]

Personnellement, je suis assez partisan du concept <longueur><valeur>

Cela permet d'abord d'allouer un buffer de réception.
Cela permet aussi d'assurer la synchronisation emission/réception. En effet, 3 émissions TCP peuvent produire 2 réceptions et l'inverse aussi, c'est à dire que 2 émissions peuvent produire 3 réceptions.

[white_tentacle]

L'autre solution, sinon, c'est d'avoir un terminateur sur tes messages. Ça impose par contre d'échapper un minimum les données que tu envoies.

[poukill]

Cela permet aussi d'assurer la synchronisation emission/réception. En effet, 3 émissions TCP peuvent produire 2 réceptions et l'inverse aussi, c'est à dire que 2 émissions peuvent produire 3 réceptions.

C'est clair, c'est vraiment le principal problème je trouve. On est partisan du même type de fonctionnement. Ce qui m'a fait poser cette question, c'est que Khayyam dans son tuto récupère de manière brute des données sur le réseau et désérialise à la volée. Comment être sûr qu'on a pas récupèrer des octets en plus ou moins? La désérialisation échoue dans ce cas là non? J'ai un gros doute sur le bon fonctionnement de cette architecture

L'autre solution, sinon, c'est d'avoir un terminateur sur tes messages. Ça impose par contre d'échapper un minimum les données que tu envoies.

C'est effectivement une solution que j'avais utilisé il y a longtemps. Ca me semble moins adapté en général, mais oui j'avais eu de bons résultats!

[Mat007]

Salut,

Comment être sûr qu'on a pas récupèrer des octets en plus ou moins?

C'est la couche d'en-dessous (ici Boost.Asio) qui te garantit ça puisque tu lui demandes de te réveiller après avoir reçu un certains nombre d'octets et pas avant ni après.

MAT.

[poukill]

Salut,
C'est la couche d'en-dessous (ici Boost.Asio) qui te garantit ça puisque tu lui demandes de te réveiller après avoir reçu un certains nombre d'octets et pas avant ni après.
MAT.

Là je parlais du cas où justement on n'envoie PAS la taille des données avant les données elles-mêmes!
Sinon oui, je suis d'accord avec toi dans le cas <longueur><valeur>

[poukill]

Du coup, je vais rester sur mon idée de <longueur><valeur>.
Mais par contre, j'aimerai toujours savoir comment la première méthode que j'ai évoquée dans mon post du haut (cf tuto de Khayyam) peut fonctionner correctement??
Si quelqu'un a la réponse...