Discussion :

[erqsor]

Bonjour,

J'ai réalisé un programme qui permet de transférer des fichiers en binaire. Celui-ci fonctionne bien, cependant j'aimerai en savoir plus sur la taille recommandée des paquets pour découper les fichiers binaires (je pense qu'il y a plusieurs paramètres à prendre en compte pour cela comme la vitesse de débit voulue) et les techniques de gestion du débit (Comment permettre à un client de choisir le débit max).

Pour l'instant mon programme envoie toutes les données à la suite sans délais.

Connaissez vous des ressources sur lesquelles je pourrai me documenter à ce propos ?

[Obsidian]

Bonjour,

En général, c'est le rôle de la pile réseau de ton système d'exploitation de gérer cela. Si tu transfères ton fichier via un port TCP, tout cela est fait automatiquement. Quel protocole ton programme utilise-t-il ?

En tout cas, tu peux déjà jeter un œil à la MTU et à la QoS.

[Joker-eph]

Dès que tu veux laisser l'utilisateur contrôler le débit max, ce n'est plus le système d'exploitation qui s'en occupe, et la question de découper de manière plus adaptée pour qu'il y ait moins de job pour la pile réseau de l'OS ne me semble pas une mauvaise idée...

[contremaitre]

Heu, penser que tu puisses decharger la pile reseau de l'OS avec ton petit programme, c'est etre un peu pretentieux vu le nombre de personnes qui ont travaillés sur cette pile reseau et les algos qui sont derriere...

[Joker-eph]

Non, à partir du moment ou tu as des données à transmettre, mais que tu ne les transmets volontairement pas, c'est très pertinent.
Par exemple pour te limiter à 10kb/s tu peux transmettre à la pile de l'OS 10octets toutes les millisecondes ou 100k ttes les 10secondes.

Or la pile à beau être optimisée, elle l'est "d'une certaine manière". Comme tout algo/implémentation, ça fonctionne toujours plutôt pas mal, mais ça fonctionne mieux si tu lui donnes ce qu'il attends pour le mettre dans la meilleure configuration...

De plus les objectifs de ton application peuvent être divers : latence, débit, etc. Un client FTP, un logiciel de VOIP, et un jeu en réseau ne laisse pas la pile réseau gérer leur paquets de la même manière ;-)

[erqsor]

Merci pour vos réponses.

Obsidian, je regarderai ces documentations ce soir.

En général, c'est le rôle de la pile réseau de ton système d'exploitation de gérer cela.

Cela va sans dire que l'OS envoie les données le plus rapidement possible, mais est-ce que l'OS va gérer au mieux la "bufferisation" des données en attente de transfert sur le réseau ? Y a t'il une limite ? l'OS plante t'il si un certain seuil de données est dépassé ? ou alors l'OS ralenti t'il spontanément l'exécution du programme en question ?
Je sais très bien que cela dépend des OS, mais à quel niveau ?

Vous me conseilleriez de privilégier l'envoie de gros paquets plus lentement ou l'envoie de petits paquets plus rapidement ?
A savoir que mon algo envoie actuellement des paquets de 1ko de données sans délais

[Joker-eph]

Cela va sans dire que l'OS envoie les données le plus rapidement possible, mais est-ce que l'OS va gérer au mieux la "bufferisation" des données en attente de transfert sur le réseau ? Y a t'il une limite ? l'OS plante t'il si un certain seuil de données est dépassé ? ou alors l'OS ralenti t'il spontanément l'exécution du programme en question ?

Sur des socket bloquante, quand tu fais un write(), ton programme est bloqué jusqu'à ce que les données soit prises en charge par la pile réseau. Tant qu'il y a des buffers de dispo c'est "immédiat", sinon ça peut être "long".

Vous me conseilleriez de privilégier l'envoie de gros paquets plus lentement ou l'envoie de petits paquets plus rapidement ?

gros, petit, et rapidement sont des termes très relatifs ;-)

A savoir que mon algo envoie actuellement des paquets de 1ko de données sans délais

Par exemple, sur Ethernet la MTU est de 1500octets, et il faut 40octets (minimum) pour les en-tête TCP/IP(v4), soit au mieux 1460octets.

Selon comment ta socket est initialisée (tu peux forcer du "no delay"), tu peux envoyer des paquets non remplis. C'est assez difficile à contrôler du point de vue applicatif car il n'y a pas que de l'Ethernet sur le chemin en général...

C'est aussi un compromis à trouver entre latence et efficacité d'un point de vue bande passante :

Si tu sais que tu vas transférer 100ko; il vaut mieux passer 100ko à ton write(); que de faire 100 fois l'appel système avec 1ko !

En revanche si tu sais que tu vas envoyer 100ko dans les 10 secondes qui viennent, mais pour l'instant t'as que 10ko produite, autant envoyer déjà ce que t'as....

[Obsidian]

Cela va sans dire que l'OS envoie les données le plus rapidement possible, mais est-ce que l'OS va gérer au mieux la bufferisation des données en attente de transfert sur le réseau ?

En soi, oui.

D'abord parce que, gérant le réseau, l'O.S. va être confronté exactement aux mêmes problèmes que toi et ce, pour tous les processus. Ensuite parce que les protocoles les plus utilisés sont prévus pour être tolérants aux erreurs de transmission et autres problèmes.

Le TCP, par exemple, est un protocole fait pour fonctionner; en principe, au dessus de l'IP. C'est un protocole orienté connexion, qui simule un canal de données continu (comme un pipe ou un fichier), alors qu'il s'appuie sur un protocole à datagrammes (envoi de messages de taille fixe). C'est le protocole qui se charge de s'assurer que tous les messages sont arrivés et de les trier si jamais tu les reçois dans le désordre.

Et là, on ne parle que des protocoles Internet. Il y a 15 à 20 ans (voire trente), on utilisait les réseaux Novell en entreprise à base de IPX/SPX. Autres procotoles, donc, mais confrontés aux mêmes problèmes.

En dessous de cela, il y a les couches physique et de liaison du modèle OSI, chargés de pallier les problèmes physiques de transmission. On y trouve des procédés de correction d'erreur et autres.

Y a t'il une limite ?

Toujours. Mais en général, celle-ci peut être paramétrée.

l'OS plante t'il si un certain seuil de données est dépassé ?

J'espère bien que non. Planter n'est JAMAIS un comportement normal, surtout s'il est prévisible.

Cela dit, certaines vieilles versions de Windows étaient réputées pour cela (WinNuke) et on voit de temps en temps certains unixoïdes, comme Linux, même très robustes (*BSD) faire des kernel panic quand la charge devient trop importante, mais c'est très rare et en général vite corrigé.

ou alors l'OS ralenti t'il spontanément l'exécution du programme en question ? Je sais très bien que cela dépend des OS, mais à quel niveau ?

Les réponses à toutes tes questions dépendent du protocole que tu utilises actuellement pour transmettre tes fichiers. Dis-nous ce que tu utilises et/ou montre-nous ton code (avec les balises [code] et [/code]).

Si l'O.S. ne peut pas transmettre une donnée ou ne peut la recevoir parce qu'il est plein, il entre dans l'un de ces deux cas :

• En mode bloquant (par défaut, généralement) : l'appel reste en attente jusqu'à ce que cela se libère. Donc, ton programme ne s'aperçoit de rien ;
• En mode non-bloquant, ton appel se termine immédiatement avec un code d'erreur tel que EAGAIN, t'invitant littéralement à « réessayer plus tard ».

Vous me conseilleriez de privilégier l'envoie de gros paquets plus lentement ou l'envoie de petits paquets plus rapidement ? A savoir que mon algo envoie actuellement des paquets de 1ko de données.

Si tu utilises un protocole à datagrammes et que tu es obligé de découper tes données, c'est une idée généralement bonne de récupérer la taille de la charge utile de ces datagrammes à l'entrée dans ton programme, et de t'y tenir. Si tu utilises un protocole de type stream, envoie les données linéairement sans te soucier de leur taille.

La question est : comment comptes-tu faire faire des pauses à ton programme ? Parce que si ça peut être une bonne idée quand le réseau est congestionné, ça peut en revanche devenir pénible quand il n'y a personne dessus mais que ton programme ralentit le transfert pour rien.

Il y a deux cas où ralentir artificiellement la transmission de données est lorsque cela concerne des paramètres qui ne sont pas directement mesurables par ton programme ou qui ne sont pas techniques : si tu fais un aspirateur de sites, par exemple, il est effectivement de bon ton de faire ses requêtes à intervalles écartés, sinon cela peut être considéré comme un type de déni de service et le webmaster va vite te mettre sur sa liste noire.

L'autre cas est celui où ton programme va être distribué : les accès réseau vont être multipliées par le nombre d'instances de ton programme et cela peut vite tourner à l'embouteillage si ce n'est pas régulé proprement. Mais dans ce cas de figure, c'est encore la gestion réseau de l'O.S. qui jouera le rôle le plus important. Ton programme devra surtout être conçu pour tenir compte de signaux extérieurs plutôt qu'émettre à l'aveuglette.

A contrario, Il y a une chose que tu dois toujours t'efforcer de faire : c'est minimiser la quantité de données à envoyer : d'abord parce que tous les réseaux ne sont pas gratuits, et que certains sont tarifiés à la quantité de données envoyées, ce qui peut grimper très vite, comme les réseaux 3G des mobiles.

D'abord, parce que c'est directement corrélé : moins de données à émettre = durée raccourcie (égale, dans le pire des cas), ce qui va à l'encontre de ton système de temporisation. Ensuite, lorsque le transfert est terminé, tu peux libérer le canal et les ressources qu'il mobilise, ce qui peut avoir un coût là aussi. Ceux qui n'ont pas encore l'A.D.S.L. et qui utilisent le RTC pour se connecter à Internet voient bien de quoi je parle.

[erqsor]

Merci pour ces informations.

Voila quelques détails sur mon programme :
- Tout d'abord c'est un programme de synchronisation qui permet à tout client s'y connectant de télécharger des fichiers manquants, modifiés, ou corrompus répertoriés par le serveur (donc transfert de fichiers de serveur vers client uniquement)
- J'utilise Qt pour la portabilité du programme.
- Je travaille sous Windows Seven (voire XP) pour mes tests mais mon programme devra fonctionner pour toutes les plateformes.
- J'envoie les données par le protocole TCP.

Pour l'instant l'application fonctionne en thread unique mais j'envisage de développer les fonctionnalités suivantes :
- Créer un thread pour l'upload par client connecté.
- Limiter le nombre de connexions en fonction de la bande passante en upload disponible du serveur (question à étudier car je ne vois pas encore bien comment je vais agencer tout ça ^^).
- Limiter la vitesse de téléchargement de chaque client si beaucoup de clients sont connectés en même temps.
- Et pourquoi pas permettre au client de limiter la vitesse de téléchargement s'il souhaite faire autre chose sur internet.

Dites moi si mes choix vous paraissent judicieux (ou non