Discussion :

[petitours]

Bonjour

Je me lance dans le TCP IP (windows form) et je suis confronté à un temps de latence gênant

Sur un clic bouton j'ouvre un socket (enfin c'est ce que je pense faire) avec

Code :

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

TcpClient client = new TcpClient("nom machine", port);

et ça prend 1 seconde environ.

Est ce un temps incompressible ? d'où vient-il ?
Sinon sur quels leviers puis je travailler pour réduire ce temps ? Puis-je par exemple créer le TcpClient à l'ouverture de l'appli et ne le fermer qu'à la fermeture de l'appli ?

merci

Le code complet de mon envoi (puis attente de l'écho en réponse), le tout largement pompé dans les exemples du MSDN

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
      private void btEnvoi_Click(object sender, EventArgs e)
        {
 
            try {
 
                //TcpClient client = new TcpClient(Dns.GetHostName(), port);
                TcpClient client = new TcpClient("nom machine", port);
 
 
 
            String message = "Coucou TCP !!!" + "<EOF>";
 
            // Translate the passed message into ASCII and store it as a Byte array.
            Byte[] data = System.Text.Encoding.ASCII.GetBytes(message);
 
            // Get a client stream for reading and writing.
            //  Stream stream = client.GetStream();
 
           NetworkStream stream = client.GetStream();
 
            // Send the message to the connected TcpServer. 
            stream.Write(data, 0, data.Length);
 
            TxtServeur.AppendText("envoi de : " + message + "\n");
                // Receive the TcpServer.response.
 
                // Buffer to store the response bytes.
                data = new Byte[256];
 
                // String to store the response ASCII representation.
                String responseData = String.Empty;
 
                // Read the first batch of the TcpServer response bytes.
                Int32 bytes = stream.Read(data, 0, data.Length);
                responseData = System.Text.Encoding.ASCII.GetString(data, 0, bytes);
                TxtServeur.AppendText("reception de : " + responseData +"\n\n");
 
                // Close everything.
               stream.Close();
               client.Close();
            }
            catch (ArgumentNullException ex)
            {
                TxtServeur.AppendText("erreur : " + ex + "\n");
            }
            catch (SocketException ex2)
            {
                TxtServeur.AppendText("Socket erreur : " + ex2 + "\n");
            }

[petitours]

Un peu de logique m'aurait surement aidé...

En utilisant l'adresse IP plutôt que le nom d’hôte ça devient immédiat

Code :

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

TcpClient client = new TcpClient("192.168.0.43", port);

L'absence de réponse à ma question, autant ici que sur google m'a obligé à reconsidérer la chose plus logiquement.

Merci

[theMonz31]

Bonjour

Parfois, le TCPClient peut prendre un peu de temps car il faut que le serveur réponde et celà peut aussi être un peu long...

Perso, quand je vais de la connexion réseau, je fais en sorte que, lors d'envoi de données, j'utilise un TCPClient ayant déjà été crée précédemment...

L'intérêt est que, comme la connexion socket est déjà établi, tu n'as plus qu'à envoyer les données... après, ça oblige à gérer un peu l'aspect perte de connexion,
mais ça reste jouable et le gain de temps est quand même important

Surtout si coté serveur, tu utilises une connexion pour savoir qu'un utilisateur est là... et encore plus si tu souhaites que le serveur puisse envoyer au client des données !!!

[petitours]

Bonjour

Remarque très pertinente, merci theMonz31

Je bosse sur un système électronique qui doit envoyer des données périodiquement sur un ou plusieurs serveurs distants et par ailleurs je dois pouvoir envoyer des ordres au système.
Si Je comprends la logique je pourrais me dispenser de gérer un serveur coté électronique ; elle serait que client, ouvrirait un socket avec x serveurs distants qui pourraient tous autant recevoir les datas que envoyer un ordre, via ce socket ouvert par l'électronique.

L'avantage de faire ainsi c'est de le pas avoir des serveur à gérer coté électronique
L'inconvénient est que tous les serveurs susceptibles d'envoyer un ordre doivent être connus à l'avance pour que l'électronique puisse s'y connecter. Cet inconvénient peut sans doute être un avantage de sécurité (seul un serveur paramétré dans l’électronique peut lui envoyer des ordres)

C'est cohérent ce que je comprends de la réponse ?

[theMonz31]

Salut

Quand je vois ton système, je me dis que tu devrais regarder du coté du protocole MQTT...

MQTT (basé sur les sockets of course) permet de définir des "forums" de discussions sur le réseau.

Il suffit d'avoir UN serveur MQTT (3 lignes en .Net) et ensuite, les clients n'ont qu'à émettre sur un sujet... et les recevoir en s'y abonnant !!!

Avec un tel système, tu fais facilement de la communication entre système et l'intérêt est que, même si un client n'écoutait pas (car déconnecté par exemple)
il peut recevoir le dernier message !!!

Bref, c'est vraiment un truc top pour des appareils électroniques... et autres !!

et s'est vraiment rapide...

Le gros intérêt est que l'émetteur ne connait pas les clients qui écoutent... donc, pas besoin d'avoir une liste de personne à qui envoyer les données, tu te contentes
de faire un truc genre :

Code :

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

1
2
 
MAClasse.Subscribe("Sujet xxx", byte[]);

ET tous ceux abonnées à ce sujet recevront les données...

Après, libre à toi d'avoir des "sujets" qui permettent de configurer, etc...

J'ai comme ça développé un Tchat Texte entre du Windows CE / Android (xamarin) / Windows 8 super facilement (car MQTT existe sur toutes ces plateformes)...

Et j'ai vu des projets faisant de la communication MQTT entre Arduino et le reste du monde...