Discussion :

[Alpha573]

Bonjour,
Je bosse actuellement sur un petit projet.
Je dois faire un petit serveur qui écoute sur le port 18000.
Lorsqu'un client se connecte et envoi ça chaine de caractère, en fonction du deuxième caractère, le serveur lance un thread spécifique, effectue le traitement et renvoie le resulat par la socket du client.
Exemple : le serveur recoit le caractere 'i' : il lance un thread, effectu le traitement (ici mathématique) et renvoit le résultat dans la socket du client

Mon problème c'est de pourvoir transférer proprement la socket à un thread et de pourvoir renvoyer les résultat par cette socket.

Le thread créé lance un foncteur.

Voici mon code

main.cpp

Code :

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

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
#include <stdio.h>
#include <stdlib.h>
#include <string>
#include <cstring>
#include <unistd.h>
#include <boost/asio.hpp>
#include <boost/thread/thread.hpp>
#include <iostream>
#include "calculFrey.h"
 
using boost::asio::ip::tcp;
using namespace boost;
using namespace std;
 
int main(int argc, char* argv[])
{
    //On déclare une socket serveur et on écoute
    try
    {
        //Création de la socket et écooute
        boost::asio::io_service io_service;
        tcp::acceptor acceptor(io_service, tcp::endpoint(tcp::v4(), 18000));
 
        cout<<"Programme prêt."<<endl;
        cout<<"Attente des requêtes..."<<endl;
 
        //On attends les connections
        for(;;)
        {
            //Attente des connections
            tcp::socket socket(io_service);
            acceptor.accept(socket);
 
 
            //Réception de la requête
            boost::array<char, 128> buf;
            boost::system::error_code error;
            socket.read_some(boost::asio::buffer(buf), error);
            string req=buf.data();
 
            if(req.at(1)=='i')
            {
                calculFrey frey(&socket); //Instanciation du fonctor avec l'adresse de la socket client
                thread t(frey); //Lancement du fonctor dans le thread
            }
        }
 
    }
    catch (std::exception& e)
    {
        std::cerr << e.what() << std::endl;
    }
}

calculFrey

Code :

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

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
#ifndef CALCULFREY_H
 
#define CALCULFREY_H
 
 
#include <boost/asio.hpp>
#include <boost/thread/thread.hpp>
#include <iostream>
using boost::asio::ip::tcp;
using namespace boost;
using namespace std;
 
/**Classe functor permettant de lancer un calcul pour Frey*/
 
 
 
class calculFrey
 
{
    private:
    tcp::socket* sock;
 
 
    public:
        calculFrey(tcp::socket* sock)
        {
            this->sock=sock;
            cout<<"Adresse de la socket dans le foncteur"<<sock<<endl;
        }
        /**Surcharge de l'opérateur ()  pour faire le functor*/
        void operator()(void)
        {
            cout<<"Passage dans le functore pour Frey"<<endl;
            boost::asio::write(*this->sock, boost::asio::buffer("hello !"));
        }
 
};
 
 
 
#endif // CALCULFREY_H

J'ai une solution qui n'en n'est pas vraiment une car la socket se ferme avant que le thread ne puisse écrire dedans.

Le problème c'est que la connection se ferme dès que le serveur à recu la chaine de caractères le code suivant me lève une exception expliquant que j'utilise un mauvais descripteur de socket :

Code :

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

boost::asio::write(*this->sock, boost::asio::buffer("hello !"));

Donc j'ai plusieurs questions :
-Comment passer à un foncteur des arguments ?
-Comment faire pour pouvoir envoyer une socket dans le thread et écrire dessus ?
-L'architecture du programme est-elle mauvaise ?

Merci d'avoir prit le temps d'arriver au bout.

[Emmanuel Deloget]

Pourquoi passer par un pointeur ?

La réponse a ta question est : lorsque tu atteins la fin du for (juste après le if), la socket est détruite, et une autre est construite à la place. Du coup, puisque ton code est exécuté de manière asynchrone, tu pointes sur un destructeur invalide.

[Alpha573]

Oui j'ai bien compris que je pointais sur un truc qui existe plus.
Mais comment régler ce problème ?

Je le fais avec un pointeur parce-qu'en passage par valeur le compilo gueule.

Merci.

[Emmanuel Deloget]

C'est une très bonne question. Puisque Boost.asio n'accepte pas de copie ses sockets (et je me demande bien pourquoi ; si ce n'est un design un peu étrange qui considère qu'une socket UDP et une socket TCP, c'est la même chose à la base), il faut aller au delà.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
class calculFrey
{
private:
    tcp::socket sock;
 
 
public:
        calculFrey(boost::asio::io_service& service, tcp::socket::native_type sockfd)
        : sock(service, tcp().protocol(), sockfd)
        { }

        /**Surcharge de l'opérateur ()  pour faire le functor*/
        void operator()()
        {
            cout<<"Passage dans le functore pour Frey"<<endl;
            boost::asio::write(sock, boost::asio::buffer("hello !"));
        }
 };

Code :

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

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
 
#include <boost/thread/thread.hpp>
#include <iostream>
#include "calculFrey.h"
 
using boost::asio::ip::tcp;
using namespace boost;
using namespace std;
 
int main(int argc, char* argv[])
{
    //On déclare une socket serveur et on écoute
    try
    {
        //Création de la socket et écooute
        boost::asio::io_service io_service;
        tcp::acceptor acceptor(io_service, tcp::endpoint(tcp::v4(), 18000));
 
        cout<<"Programme prêt."<<endl;
        cout<<"Attente des requêtes..."<<endl;
 
        //On attends les connections
        for(;;)
        {
            //Attente des connections
            tcp::socket socket(io_service);
            acceptor.accept(socket);
 
 
            //Réception de la requête
            boost::array<char, 128> buf;
            boost::system::error_code error;
            socket.read_some(boost::asio::buffer(buf), error);
            string req=buf.data();
 
            if(req.at(1)=='i')
            {
                //Lancement du fonctor dans le thread
                thread t(calculFrey(io_service, socket.native()); 
                // la socket est vidée de son contenu, de la manière la 
                // plus trash possible
                socket.assign(tcp().protocol(), 0);
            }
        }
     }
    catch (std::exception& e)
    {
        std::cerr << e.what() << std::endl;
    }
}

Si quelqu'un d'autre voit une autre solution, je suis preneur aussi. A lire la doc, je ne vois pas mieux, et je ne sais même pas si ça passera (le assign() pourrait être un poil violent et fermer la socket avant de faire le assign(), auquel cas, il faut complètement repenser le design).

On notera quand même que cette architecture est très commune, et pourtant, si j'ai bien tout lu la doc de boost::asio, impossible à mettre en place proprement avec cette librairie (il faudrait un move constructor à la classe tcp::socket, ou un équivalent). C'est assez décevant, vu le potentiel de cette librairie.

(note: une autre solution existe, à base de bost::shared_ptr. Mais je n'aime pas les pointeurs intelligents).

[Alpha573]

Ha enfin quelqu'un qui me comprends :-)
Je test ça demain et je vous tient au courant.
Merci beaucoup !

[poukill]

(note: une autre solution existe, à base de bost::shared_ptr. Mais je n'aime pas les pointeurs intelligents).

Je sais que c'est hors topic, mais je serai curieux d'avoir ton avis dessus... Perso je trouve ça hyper pratique, et tout mon code est infesté de scoped_ptr et shared_ptr....

[Emmanuel Deloget]

Je sais que c'est hors topic, mais je serai curieux d'avoir ton avis dessus... Perso je trouve ça hyper pratique, et tout mon code est infesté de scoped_ptr et shared_ptr....

scoped_ptr<> a un intérêt (tout comme auto_ptr, mais en mieux). shared_ptr<> est utilisé pour ne pas avoir à gérer la propriété des objets (qui appartient à quoi). Hors, sans notion de propriété, il n'y a pas de notion de durée de vie (d'où l'utilisation d'un pointeur qui se détruit tout seul, comme un grand, quand personne ne l'utilise plus). Ca veut dire en gros que tu ne contrôle rien, que le plus petit changement dans ton code peut avoir des conséquence que tu ne peux pas prévoir, etc. C'est une horreur en maintenance, mais aussi en architecture - car réaliser une architecture, c'est mettre en évidence les liens qui existent entre les différents concepts (classes) de l'application, y compris les liens de propriété. shared_ptr<> ne met en évidence aucun lien, voire les cache, ce qui participe à rendre bancal une architecture.

C'est pratique, oui, comme goto l'est. Après avoir tapé sur les tête des singletons pendant des années, voici maintenant venir le temps des pointeurs intelligents qui font des choses inintelligibles

[Alpha573]

(le assign() pourrait être un poil violent et fermer la socket avant de faire le assign(), auquel cas, il faut complètement repenser le design).

Humm repenser le design... Tu vois quoi comme architecture ?

[Emmanuel Deloget]

Humm repenser le design... Tu vois quoi comme architecture ?

Rien de vraiment intelligent et proche de ce que tu veux faire, vu le design d'asio. J'ai peur que les shared_ptr soient la seule solution pour implémenter ce type de pattern.

L'autre solution est de faire comme la doc d'asio le dit dans HttpServer3 (un pool de threads).

[Goten]

Rien de vraiment intelligent et proche de ce que tu veux faire, vu le design d'asio. J'ai peur que les shared_ptr soient la seule solution pour implémenter ce type de pattern.

L'autre solution est de faire comme la doc d'asio le dit dans HttpServer3 (un pool de threads).

Tu reproches quoi au design d'asio? (il est vraiment très très bien branlé amha)

[Emmanuel Deloget]

Tu reproches quoi au design d'asio? (il est vraiment très très bien branlé amha)

http://www.gamedev.net/blog/198/entr...rything-right/

Je compte traduire ça ce soir pour le mettre sur mon blog (de manière plus étendue, avec beaucoup plus de détails).

[NoIdea]

scoped_ptr<> a un intérêt (tout comme auto_ptr, mais en mieux). shared_ptr<> est utilisé pour ne pas avoir à gérer la propriété des objets (qui appartient à quoi). Hors, sans notion de propriété, il n'y a pas de notion de durée de vie (d'où l'utilisation d'un pointeur qui se détruit tout seul, comme un grand, quand personne ne l'utilise plus). Ca veut dire en gros que tu ne contrôle rien, que le plus petit changement dans ton code peut avoir des conséquence que tu ne peux pas prévoir, etc. C'est une horreur en maintenance, mais aussi en architecture - car réaliser une architecture, c'est mettre en évidence les liens qui existent entre les différents concepts (classes) de l'application, y compris les liens de propriété. shared_ptr<> ne met en évidence aucun lien, voire les cache, ce qui participe à rendre bancal une architecture.

Je suis a 100% d'accord.

Si tu veux revoir une discussion (à laquelle je suis surpris que tu n'aie pas participer vu ton opinion) : Pointeurs intelligents vs pointeurs brut.

[Flob90]

<HS>
@NoIdea: Je ne crois pas que Emmanuel soit pour l'utilisation massive de pointeur brut pour les allocations dynamique, mais plutot contre l'utilisation tout azimute de la notion de SharedOwnership (responsabilité partagé), et qu'il préférerait voir plus de StrictOwnership, c'est à dire que les gens définissent clairement les reponsabilités des objets entre eux tout en utilisant le RAII pour gérer les destructions (ce que propose unique_ptr par exemple). Et personnelement, ce genre de pointeur reste un type spécifique de pointeur intelligent ... (c'est loin d'être un pointeur brut)
</HS>

[gl]

http://www.gamedev.net/blog/198/entr...rything-right/

Je compte traduire ça ce soir pour le mettre sur mon blog (de manière plus étendue, avec beaucoup plus de détails).

Je suis d'accord que le fait de ne pas pouvoir transférer le pointeur pose des problèmes. Maintenant je ne suis pas persuadé que cela ait vraiment un sens de copier des sockets, avoir des sockets déplaçable est suffisant pour résoudre les problèmes de transfert et fait plus de sens, ama, que d'avoir des sockets copiables.

[Emmanuel Deloget]

Je suis d'accord que le fait de ne pas pouvoir transférer le pointeur pose des problèmes. Maintenant je ne suis pas persuadé que cela ait vraiment un sens de copier des sockets, avoir des sockets déplaçable est suffisant pour résoudre les problèmes de transfert et fait plus de sens, ama, que d'avoir des sockets copiables.

C'est tout à fait possible, encore que cette idée de weak_socket est quelque chose à creuser. Mais les sockets d'Asio ne sont même pas déplaçable, alors le problème est réglé

[Flob90]

@Emmanuel: Et que penses-tu (si tu l'as regardé) de l'architecture choisie par Poco pour son module réseaux (overview : http://pocoproject.org/slides/200-Network.pdf) ? J'ai regardé (très rapidement) et il ne me semble pas il y avoir les problèmes que tu soulèves dans ton article.

[Alpha573]

Merci pour les infos.
Pour pocco j'ai pas regarder, mais ça fait déjà 2 fois que je change de méthode pour mon problème et je pense que je n'aurais pas le temps de me refaire à une autre librairie mais merci.
Mais concrètement vous me conseillez de faire comment ?
Parce-que je commence à me perdre...
Il faut absolument que je puisse utiliser la socket d'un client dans le thread.
Et niveau temps, pour mon projet ça deviens juste...
Je vais regarder le pool de thread du tuto de la doc.
Merci !

[Goten]

C'est tout à fait possible, encore que cette idée de weak_socket est quelque chose à creuser. Mais les sockets d'Asio ne sont même pas déplaçable, alors le problème est réglé

Il me semblait que les sockets étaient movable mais parfois ma mémoire me joue des tours...

[gl]

Mais les sockets d'Asio ne sont même pas déplaçable, alors le problème est réglé

Certes.

[Emmanuel Deloget]

@Emmanuel: Et que penses-tu (si tu l'as regardé) de l'architecture choisie par Poco pour son module réseaux (overview : http://pocoproject.org/slides/200-Network.pdf) ? J'ai regardé (très rapidement) et il ne me semble pas il y avoir les problèmes que tu soulèves dans ton article.

J'ai regardé (je ne connaissais pas avant). Il me semble au contraire que certains des reproches que je fais à Asio sont encore présents:

* les sockets ont sont copiable (Pimpl + shared_ptr en interne, full value semantics)

* mais elles continuent de proposer des services étrange (bind, listen, ... ; les sockets sont un wrapper autour de l'API BSD). Ce n'est pas à un objet socket public de proposer ces services. Elles n'ont pas focus - ce qui est acceptable pour encapsuler l'accès à un device l'est moin pour encapsuler un accès à une socket.

Sinon, il faut avouer que l'utilisation de la librairie est très claire. J'ai un doute sur les performances réseau (on passe par plusieurs couches d'abstraction qui sont implémentées sous la forme de classes abstraites), mais dans la plupart des cas, ce n'est pas vraiment le point important.