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...