Bonjour

J'ai plusieurs applications (1 Serveur et x Clients en .Net Framework 4.8) qui communique via le protocole TCP (TCPListener de C#) et j'ai remarqué quelque chose d'assez embêtant pour nos applications. Si on fait une copie d'un fichier d'un PC client vers le PC serveur, en utilisant l'explorateur de Windows (donc le client à accès à certain dossier du serveur), les communications de mes application entre ce client et le serveur sont coupées ou très perturbées (parmi les communications, il y a un watchdog entre le serveur et le client et pendant la copie le clientne reçoit plus les watchdog,). J'ai aussi le souci même avec le firewall désactivé des deux côtés

Les 2 PCs (Client et serveur) sont sur le même réseau, il y a juste un switch entre les deux.

Pour constater le problème il faut que le fichier soir assez volumineux surtout si vous êtes sur du Gigabit.

J'ai essayer le Quality of Service de Windows, mais ça n'a rien changé pendant mon test.

Je préfèrerai rester dans le protocole TCP, si possible.

Je viens vers vous pour savoir s'il possible (Je manque un peu d'expérience sur la partie réseau) :

- que mes communications ne soit perturbées (A part le QoS Windows je n'ai pas trop d'idée)

- ou alors limiter la vitesse des copies de fichier, pour ne pas prendre toute la bande passante, comment (par windows ca serait mieux que de rajouter un logiciel tier pour le faire) ?

- ou s'il y a des modifications des propriétés des réseaux ethernet qui permettent d'éviter ce problème

- Tout autres idées qui permettraient de ne pas avoir cette perturbation

J'ai fais 2 petits soft de test Client et Serveur, qui permettent de constater ce problème (je peux les fournir si besoin)

S'il manque des informations, n'hésitez pas à me le dire j'essaierai d'y répondre au plus vite

Merci de m'avoir lu

Je pense que vous confondez "watchdog" et "hearthbeat".

Vous devriez avoir plus d'information sur le "problème" avant de choisir une solution.

Je pense que vous devriez utiliser un outil comme WireShark pour avoir ces informations.

TCP/IP a normalement tout ce qu'il faut pour détecter des déconnexions (même si ça prend littéralement 2 minutes pour être détecter, avec le paramétrage classique). Pourquoi rajouter un "hearbeat" à celui intégré au TCP/IP, en moins bien ?

IPv4 ou IPv6 ?

etc...

(on est un peu dans le brouillard au niveau des contraintes/fonctionnalités nécessaire à votre application, TCP/IP n'est pas la panacée.)

Merci pour votre réponse,je m'aperçois que j'ai pas étais assez exhaustif.

Le client et le serveur s'envoient des messages en TCP régulièrement pour signifier qu'ils sont encore actif (en effet c'est plus un heartbeat qu'un watchdog)

Le client et le serveur s'envoient d'autres messages mais j'ai préféré rester sur ce message simple (qui ne passe pas durant la copie)

J'ai déjà fait une analyse avec wireshark et en effet durant la période de la copie du fichier, je ne vois plus mes messages.

2 mins pour détecter une déconnexion c'est trop long pour ce qu'on en fait c'est en parti pour cette raison que des Heartbeat ont été rajouté.

Tout est en IPv4

Les clients envoient régulièrement au serveur des informations, qui doivent être enregistrées dans une BDD. c'est message sont envoyés régulièrement par tous les clients (en gros un client envoie un message par seconde)

Désolé pour le délai de réponse (mais j'ai eu une urgence)

>Tout est en IPv4

On est donc avec un protocole conçu dans les années 1970, donc pas de QoS (Quality of Service) de base.

TCP/IP a un mécanisme de "KeepAlive" qui est plus ou moins paramétrable en fonction des plateformes.

Donc, si vous faites du spécifique, pourquoi ne pas configurer ce "KeepAlive" à vos besoins ?

>Le client et le serveur s'envoient des messages en TCP régulièrement pour signifier qu'ils sont encore actif

Vous avez donc implémenté un protocole au-dessus de TCP/IP.

Vous êtes sûr que vous avez bien respecter l'architecture OSI de l'ISO ?

Pour moi, votre heartbeat au-dessus de TCP/IP, ça colle pas avec l'OSI.

Pourquoi utiliser TCP/IP si les services "offerts" ne correspondent pas à vos besoins ? Pourquoi pas UDP, par exemple ?

Si vous voulez toujours utiliser TCP/IP, il faudrait que votre mécanisme s'intègre plus dans la couche TCP/IP pour utiliser ses informations internes de cette couche => drivers réseaux custom par exemple.

Ne pouvez-vous pas interroger la couche TCP/IP pour avoir le timestamp du dernier message avant de faire péter une "déconnexion" ?

En résumé, j'ai l'impression qu'il y a beaucoup de "trous dans la raquette" au niveau de la conception de votre protocole, non ?

EDIT: j'ai pas tilté qu'on était sur un forum .NET. Il y a des chances d'avoir plus de choix en passant par du "natif".

-
Edité par bacelar 23 juillet 2024 à 21:19:38

Bonjour encore merci pour vos réponses

En effet, moi et ceux qui ont développés les clients et le serveur, manquons surement d'expérience sur le protocole TCP/IP. Mais je ne peux pas revenir en arrière maintenant.

La raison de pourquoi le TCP//IP a été choisi, c'était pour la sécurité de l'envoi et de la réception des données (on n'a pas le droit de les perdre)

Mais je ne vois pas en quoi l'utilisation que nous faisons de la communication quand on fait une copie, coupe toutes les communications (pas seulement le Heartbeat)

>Mais je ne peux pas revenir en arrière maintenant.

Mauvais état d'esprit pour trouver une "bonne" solution.

On peut toujours revenir en arrière, il faut y être préparé, si nécessaire.

>c'était pour la sécurité de l'envoi et de la réception des données

Cela a été fait en faisant des choix, et c'est clairement à l'encontre d'une détection rapide d'une "déconnexion" (qui physiquement ne veut rien dire de concret).

Il n'y a rien de "magique" dans TCP. Vous pouvez très bien implémenter ces fonctionnalités vous-même.

>Mais je ne vois pas en quoi l'utilisation que nous faisons de la communication quand on fait une copie, coupe toutes les communications

Désolé, je viens de me rendre compte que j'ai fait vraisemblablement un contre-sens. Je pensais que la copie de gros fichiers passait par "vos" socket.

Si je comprends bien, c'est via des transfert type SMB, NFS, etc... que ces fichiers transitent, non ?

>coupe toutes les communications

C'est votre implémentation "simpliste" qui "coupe" le canal de communication.

TCP/IP gère très bien les congestions passagères dans des réseaux maillés.

Vos contraintes me semblent très contradictoires, surtout au vu du modèle OSI.

Pour vous, c'est quoi concrètement une "déconnexion" ? (un câble débranché ? un hotspot Wifi sans activité "couche liaison des données" depuis 2 minutes ? etc... )

TCP/IP a été conçu pour faire du "best effort" dans un contexte où on cherchait la résilience du réseau (ARPANET, guerre froide, etc...), pas dans un contexte de réseau d'opérateur téléphonique exigeant peu de pertes (ou réception hors délais) ou de gigue temporelle comme un réseau ATM.

Pour les protocoles de transfert de fichiers, on est dans la même philosophie du "best effort", par défaut.

Pour le protocole SMB, par exemple, il est possible de moduler la charge maximale :

Set-SmbBandwidthLimit (SmbShare) | Microsoft Learn

etc...

Mais j'ai du mal à comprendre pourquoi votre "protocole" de niveau 5 (Session) serait "naturellement" résistant à la congestion réseau.

Si vous avez besoin de réserver des ressources, c'est le rôle de protocoles comme RSVP (Resource Reservation Protocol — Wikipédia (wikipedia.org)), pas de TCP/IP.

Comme votre architecture hardware est simple, pourquoi ne pas chercher, dans les protocoles de bas niveau supportés par votre switch, ceux qui permettraient de faire de la ségrégation de trafic ?

Moi, je ne comprends pas trop votre étonnement de "ça marche pas !", quand on ne voit dans votre conception rien pour vous prémunir des problèmes habituels en réseau.

-
Edité par bacelar 26 juillet 2024 à 15:18:16

On peut toujours revenir en arrière, il faut y être préparé, si nécessaire.<

Si je présente les bon arguments,je vais peut être pouvoir faire les modifications qui s'imposent au niveau communication

>Cela a été fait en faisant des choix, et c'est clairement à l'encontre d'une détection rapide d'une "déconnexion" (qui physiquement ne veut rien dire de concret).

Il n'y a rien de "magique" dans TCP. Vous pouvez très bien implémenter ces fonctionnalités vous-même.<

La priorité c'est que les messages arrivent à l'expéditeur, c'est pour cette raison que le TCP a été choisi, je pense (je dis ça car ce n'est pas moi qui est fait ces choix, je n'ai fait que reprendre le projet)

>Désolé, je viens de me rendre compte que j'ai fait vraisemblablement un contre-sens. Je pensais que la copie de gros fichiers passait par "vos" socket.

Si je comprends bien, c'est via des transfert type SMB, NFS, etc... que ces fichiers transitent, non ?<

Alors dans Wireshark le protocol utilise pour la copie de fichier c'est du TCP (en fait, on utilise 2 explorateurs windows (un local et un ouvert sur le PC distant dans le même réseau local) pour faire la copie du fichier)

>C'est votre implémentation "simpliste" qui "coupe" le canal de communication.

TCP/IP gère très bien les congestions passagères dans des réseaux maillés.<

Je vais regarder pour refaire la communication sur mes applications de tests et voir si cela peut changer quelque chose

>Vos contraintes me semblent très contradictoires, surtout au vu du modèle OSI.

Pour vous, c'est quoi concrètement une "déconnexion" ? (un câble débranché ? un hotspot Wifi sans activité "couche liaison des données" depuis 2 minutes ? etc... )<

Tout est en filaire sur ces machines, donc oui la déconnexion c'est un câble débranché ou l'application qui a été fermé

>TCP/IP a été conçu pour faire du "best effort" dans un contexte où on cherchait la résilience du réseau (ARPANET, guerre froide, etc...), pas dans un contexte de réseau d'opérateur téléphonique exigeant peu de pertes (ou réception hors délais) ou de gigue temporelle comme un réseau ATM.

Pour les protocoles de transfert de fichiers, on est dans la même philosophie du "best effort", par défaut.

Pour le protocole SMB, par exemple, il est possible de moduler la charge maximale :

Set-SmbBandwidthLimit (SmbShare) | Microsoft Learn

etc...

Mais j'ai du mal à comprendre pourquoi votre "protocole" de niveau 5 (Session) serait "naturellement" résistant à la congestion réseau.

Si vous avez besoin de réserver des ressources, c'est le rôle de protocoles comme RSVP (Resource Reservation Protocol — Wikipédia (wikipedia.org)), pas de TCP/IP.

Comme votre architecture hardware est simple, pourquoi ne pas chercher, dans les protocoles de bas niveau supportés par votre switch, ceux qui permettraient de faire de la ségrégation de trafic ?<

Si vous pouvez me donner une piste de recherche car comme vous avez pu vous en doutez je suis loin d'être un expert en protocole réseau

>Moi, je ne comprends pas trop votre étonnement de "ça marche pas !", quand on ne voit dans votre conception rien pour vous prémunir des problèmes habituels en réseau.<

Donc c'est juste à cause de la congestion de réseau que l'on ne gère pas que le problème de communication apparait lors de la copie d'un fichier.

Il faut que j'essaye en faisant des modifications sur mes applications de tests, voir si ça se passe mieux. mais je ne vais pas avoir le temps tout de suite, hélas

Je vais aussi regarder les liens que vous m'avez donner, voir si je peux faire des tests.

Merci encore du temps que vous m'avez consacré pour me répondre. Il faut que j'étudie tout ça et que je regarde comment je pourrais le mettre en place.

>La priorité c'est que les messages arrivent à l'expéditeur, c'est pour cette raison que le TCP a été choisi, je pense<

TCP/IP ne garantit en rien que des "messages" arrivent à l'expéditeur.

TCP/IP ne travaille même pas en mode message mais en mode flux.

La "seule" chose que TCP/IP garantit, c'est que les octets acquittés par la machine destinataire ont bien été écrits dans un buffer de la stack IP de la machine, et absolument rien d'autre.

Si vous en voulez plus, c'est à vous, en tant qu'implémenteur des protocoles des couches supérieures de vous y coller. (toujours rien de magique)

Par exemple, les mécanismes "requête/réponse" de HTTP(S) sont implémentés au-dessus de TCP/IP mais c'est HTTP(S) qui fait tout le reste du boulot autre que la transmission du flux (découpage en message, utilisation de cache client, de cache serveur, compression, etc...).

>Alors dans Wireshark le protocol utilise pour la copie de fichier c'est du TCP<

Les protocoles de transfert de fichier utilisent généralement TCP/IP comme protocole de niveau transport (4/7 de l'OSI). Il faut disposer des "bons" plug-ins et correctement les configurer pour que la capture Wireshark affiche explicitement le trafic généré par ces protocoles de plus "haut" niveau comme les protocoles de transfert de fichier (FTP, SMB, etc...).

Généralement, le numéro de port TCP utilisé permet de savoir quel "service" utilise la bande passante et par conséquent quel protocoles de plus haut ce service est sensé utiliser (si le numéro est inférieur à 1024, c'est normalisé par IETF).

>Tout est en filaire sur ces machines, donc oui la déconnexion c'est un câble débranché<

TCP ne gère pas la connexion "physique", c'est la couche 1/7 de l'OSI. TCP, c'est niveau transport (4/7 de l'OSI). Si vous voulez gérer la déconnexion physique, c'est avec les drivers de cette couche que vous devez dialoguer. Mais je pense que vous vous fourvoyez et que vous n'avez pas à gérer la connexion physique (l'impédance induite calculée d'un fils en cuivre fonction du mode d'encodage des bits lors du changement de front, je ne crois pas ça concerne un "softeux").

>ou l'application qui a été fermé<

C'est quoi une application qui a "fermé" ? Si vous n'utilisez pas un OS bogué ou du millénaire dernier, si une application a un contrôle exclusif sur une demi-connexion, à la fin du processus, l'OS lance automatiquement la fermeture de sa demi-socket et l'application distante (plutôt la stack TCP/IP de l'OS) sera prévenu dans les 2 minutes "maximum". Mais généralement, si l'application n'envoie rien, elle s'en cogne que le processus distant ne dépile pas les octets qu'elle n'envoie pas. La gestion des sessions, c'est au niveau 5/7 de l'OSI, donc TCP/IP, il s'en cogne que c'est un autre processus qui récupère les octets "destinés" a un "ancien" processus (et heureusement pour les serveurs Web multi-processus).

>Si vous pouvez me donner une piste de recherche car comme vous avez pu vous en doutez je suis loin d'être un expert en protocole réseau<

Vous ne donnez pas beaucoup de détails pour bien vous conseiller. Si vous êtes dans une entreprise, vous devriez vous tourner vers vos administrateurs réseaux qui doivent avoir l'habitude de faire de la ségrégation de trafic réseau, aussi bien physiquement que virtuellement. Mais si vous n'avez qu'un switch, ils n'auront pas beaucoup d'alternative mais ils doivent connaitre les possibilités de leurs matériels réseau en termes de ségrégation.

En résumé, j'ai l'impression que vous maitrisez assez mal les concepts réseaux, ce qui fait que vous vous faites de fausses idées de comment fonctionnent les protocoles réseaux, leurs possibilités, leurs (très nombreuses) limitations, etc...

Que vos choix reposent "sur du sable"

Que vous avez du mal à réfléchir "hors du cadre" offert par l'API socket BSD conçu au début des années 1980.

etc...

(A l'arrache, au plus simple, vous collez 2 cartes réseaux aux machines clients et serveur, 1 carte dédiée pour votre application par machine, vous mettez un switch entre ces cartes "dédiées" qui ne reçoit que les trafics de votre application, ainsi votre infrastructure réseau "parallèle" sera entièrement séparée du reste. Le plus compliqué, c'est de configurer les adresses IP et les tables de routage de votre "shadow network" => demandez à vos administrateurs réseau de vous aider.)

Une autre approche, c'est de faire en sorte de limiter les perturbations des autres applications => il vous faut l'aide des administrateurs réseau qui connaissent la nature du réseau et des trafics qui y circulent.