Discussion :

[Shypster]

Bonjour,

Désolé pour le titre du post qui n'est pas explicite mais je n'ai pas trouvé autre chose.

Je souhaiterai un avis sur le morceau de code suivant :

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
private void Serveur_Load(object sender, EventArgs e)
{
	server = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp);
	ASCIIEncoding dec = new ASCIIEncoding();
	IPAddress ipserver = IPAddress.Parse("192.3.4.118");
	server.Bind(new IPEndPoint(ipserver, 80));
	server.Listen(100);
	rappelacceptsocket = new AsyncCallback(this.connexionAcceptCallback);
	server.BeginAccept(rappelacceptsocket, server);
}

private void connexionAcceptCallback(IAsyncResult asyncResult)
{
	Socket SocketClient = server.EndAccept(asyncResult);
	MessageBox.Show("Client connecté");
	server.BeginAccept(rappelacceptsocket, server);
}

J'utilise les sockets pour créer un serveur qui doit accepter les connexions entrantes qu'il recevra.

Est-ce que appeller "BeginAccept" dans un callback à chaque nouvelle connexion d'un client est propre et ne prend pas trop de ressource ?

Merci

PS : soyez indulgent sur le code, c'est seulement un code de test

[tomlev]

Est-ce que appeller "BeginAccept" dans un callback à chaque nouvelle connexion d'un client est propre et ne prend pas trop de ressource ?

A priori ce n'est pas un problème, vu que le thread du précédent BeginAccept va se terminer.

Par contre, juste une petite suggestion : si tu es en TCP, plutôt que de manipuler directement un socket bas niveau, pourquoi ne pas utiliser la classe TcpListener ? Ca te masquerait une bonne partie de la complexité des sockets...

[Shypster]

A priori ce n'est pas un problème, vu que le thread du précédent BeginAccept va se terminer.

Par contre, juste une petite suggestion : si tu es en TCP, plutôt que de manipuler directement un socket bas niveau, pourquoi ne pas utiliser la classe TcpListener ? Ca te masquerait une bonne partie de la complexité des sockets...

Oui bonne remarque, je vais plutôt utiliser un tcplistener.

J'ai une autre question dans le même contexte, du côté client je voudrais que lorsque la connexion avec le serveur est perdue et que le serveur se remet en mode écoute aprés un laps de temps indéfini le client se reconnecte automatiquement au serveur sans intervention particulière, est ce possible ou trop lourd à gérer ?

[tomlev]

J'ai une autre question dans le même contexte, du côté client je voudrais que lorsque la connexion avec le serveur est perdue et que le serveur se remet en mode écoute aprés un laps de temps indéfini le client se reconnecte automatiquement au serveur sans intervention particulière, est ce possible ou trop lourd à gérer ?

Ben tout est possible... je ne crois pas qu'il existe une façon "standard" de faire ça, il va falloir le gérer à ta façon. La plus grosse difficulté sera probablement de détecter la déconnexion, vu qu'il n'y a pas vraiment de moyen simple de tester si tu es connecté : la propriété Connected n'est pas fiable, elle peut renvoyer true alors que la connexion est perdue ; le seul moyen d'être sûr est d'essayer de transférer des données et de voir ce qui se passe...

Par contre, quel genre d'appli tu développes ? Tu as vraiment besoin de travailler au niveau TCP ? Même si tu veux rester en TCP, jette un oeil à WCF, ça pourrait pas mal te faciliter la vie

[Shypster]

Je développe une application de backup client / serveur sur réseau local.
Les sockets découlent des Winsocks que j'utilisais en Visual basic.

Il est vrai que je ne connais pas du tout les nouveaux moyens qu'offre .NET. En revanche j'ai jeté un bref coup d'oeil sur WCF, ça m'a l'air plutôt compliqué non ?

[tomlev]

En revanche j'ai jeté un bref coup d'oeil sur WCF, ça m'a l'air plutôt compliqué non ?

Oui et non... ça peut paraitre un peu effrayant au début (définition d'interfaces, configuration etc), mais en fait ce n'est pas très difficile, et une fois que c'est fait, tu peux faire complètement abstraction des aspects bas niveau de la communication. Tu te contentes de manipuler un objet distant, via un proxy, de manière totalement transparente.

Par exemple, si ton appli est un service de chat, tu ferais quelque chose comme ça :

Code :

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

1
2
3
ChatService chat = new ChatService();
chat.Login("Jack", "MotDePasse123");
chat.SendMessage("Joe", "Hey Joe !");

Et si un jour tu décides que ton service ne va plus fonctionner en TCP mais en HTTP, c'est juste un paramètre de conf à modifier...

[Shypster]

Oui et non... ça peut paraitre un peu effrayant au début (définition d'interfaces, configuration etc), mais en fait ce n'est pas très difficile, et une fois que c'est fait, tu peux faire complètement abstraction des aspects bas niveau de la communication. Tu te contentes de manipuler un objet distant, via un proxy, de manière totalement transparente.

Par exemple, si ton appli est un service de chat, tu ferais quelque chose comme ça :

Code :

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

1
2
3
ChatService chat = new ChatService();
chat.Login("Jack", "MotDePasse123");
chat.SendMessage("Joe", "Hey Joe !");

Et si un jour tu décides que ton service ne va plus fonctionner en TCP mais en HTTP, c'est juste un paramètre de conf à modifier...

Bon je me suis mis au WCF mais je me pose une question dans mon cas précis. Comment puis-je faire pour que mon serveur demande à mon client d'exécuter une tâche ? Parce que dans le sens client vers serveur pas de problème.

Merci pour tes infos.

[tomlev]

Bon je me suis mis au WCF mais je me pose une question dans mon cas précis. Comment puis-je faire pour que mon serveur demande à mon client d'exécuter une tâche ? Parce que dans le sens client vers serveur pas de problème.

Il faut créer une interface de callback pour que le serveur puisse contacter le client. Regarde dans les tutos sur Developpez, je crois qu'il y a des exemples de ça

[Shypster]

Il faut créer une interface de callback pour que le serveur puisse contacter le client. Regarde dans les tutos sur Developpez, je crois qu'il y a des exemples de ça

En m'aidant du très bon tutoriel "Chatez en wcf", j'ai presque réussi à arriver à mes fins. Mais il me reste un détail à résoudre et pas des moindres.

Comment puis-je via une interface de callback envoyer des infos à un client spécifique et non à tous les clients connectés ?

[tomlev]

Comment puis-je via une interface de callback envoyer des infos à un client spécifique et non à tous les clients connectés ?

De mémoire, je crois qu'il faut garder quelque part dans ton service l'objet callback de chaque client... par exemple, quand il se connecte, tu l'ajoutes à un dictionnaire ou quelque chose comme ça pour pouvoir y accéder plus tard. Ensuite, tu as juste à récupérer le callback vers lequel tu veux envoyer les infos.

Un truc dans ce style :

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
private Dictionary<string, IChatWCFRappel> _clientCallbacks;
 
public bool Login(string username, string password)
{
    if (Authenticate(username, password))
    {
        IChatWCFRappel callback = OperationContext.Current.GetCallbackChannel<IChatWCFRappel>();
        _clientCallbacks.Add(userName, callback);
        return true;
    }
    return false;
}
 
public bool SendMessage(Message msg)
{
    IChatWCFRappel callback;
    if (_clientCallbacks.TryGetValue(msg.ToUser, out callback))
    {
        callback.PostMessage(msg);
        return true;
    }
    return false;
}

Selon la politique d'instantiation de ton service (unique, par session, par connexion...), il faudra éventuellement déclarer le dictionnaire en statique

[Shypster]

Ok merci, tes conseils m'ont beaucoup aidé.
Dernière chose, quelles sont les différentes méthodes pour accéder aux composants graphiques de mon formulaire depuis d'autrres classes ou de faire en sorte d'informer l'utilisateur des différentes tâches qui sont effectuées dans les classes "métier" ?

Merci.

[tomlev]

Dernière chose, quelles sont les différentes méthodes pour accéder aux composants graphiques de mon formulaire depuis d'autrres classes ou de faire en sorte d'informer l'utilisateur des différentes tâches qui sont effectuées dans les classes "métier" ?

La question est un peu vague... peux-tu préciser ?

D'ailleurs, ça n'a pas de rapport avec la première question, donc ouvre plutôt une nouvelle discussion

[Shypster]

Ma dernière demande est un peu liée à ma première question, après avoir construit mon service WCF, je me retrouve avec quatre projets (le service, les interfaces de contrat, le client et le serveur hébergeant le service).

J'ai référencé dans mon projet du serveur mon service (dll) et mon contrat (dll).
J'ai dans mon service comme dans l'exemple du "Chat wcf" une méthode "connexionclient". Je voudrais par exemple que dans cette méthode quand un client se connecte, le serveur affiche dans une listview un message disant un tel s'est connecté.

Est-ce possible dans mon cas où faut-il que j'intègre les sources de mon service dans mon serveur pour ensuite hériter ma classe de service sur mon formulaire ?

[tomlev]

Je voudrais par exemple que dans cette méthode quand un client se connecte, le serveur affiche dans une listview un message disant un tel s'est connecté.

Tu pourrais déclarer un évènement ClientConnected dans l'implémentation de ton service, et t'abonner à cet évènement dans l'interface graphique.

Est-ce possible dans mon cas où faut-il que j'intègre les sources de mon service dans mon serveur pour ensuite hériter ma classe de service sur mon formulaire ?

Je ne vois pas trop ce que ça apporterait de mettre les sources dans le même projet, tu peux faire pareil en ajoutant une référence. Mettre une relation d'héritage entre le service et le formulaire, pour le coup, c'est une très mauvaise idée, c'est contraire à tous les principes de POO, et ça introduirait un couplage qui n'a pas lieu d'être entre le service et l'interface graphique

[Shypster]

Comment puis-je m y prendre pour appeler l'évènement d'une autre classe ?

[tomlev]

Comment puis-je m y prendre pour appeler l'évènement d'une autre classe ?

Qui te parle "d'appeler l'évènement" d'une autre classe ? Dans ta classe qui implémente le service, tu crées un évènement ClientConnected, que tu déclenches quand un client se connecte. Et dans ton formulaire, tu t'abonnes à l'évènement du service pour réagir à la connexion. Il n'est jamais question d'appeler un évènement d'une autre classe...

[Shypster]

Un détail m'échappe, je veux que dans ma méthode de mon évènement accéder à un composant graphique de mon formulaire.

[tomlev]

Un détail m'échappe, je veux que dans ma méthode de mon évènement accéder à un composant graphique de mon formulaire.

ben où est le problème ? La méthode qui est appelée par l'évènement est dans le code de la Form, donc elle peut accéder aux composants...

[Shypster]

Oui merci je n'avais pas mis "static" pour mon évènement et vu que à chaque connexion d'un nouveau client, je crée une nouvelle instance de ma classe "service", l'eventarg me retournait rien.

Merci.