IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Réseau C Discussion :

Estimer sa bande passante (tcp)


Sujet :

Réseau C

  1. #1
    Membre habitué
    Homme Profil pro
    Etudiant
    Inscrit en
    Février 2010
    Messages
    115
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : France, Seine Maritime (Haute Normandie)

    Informations professionnelles :
    Activité : Etudiant

    Informations forums :
    Inscription : Février 2010
    Messages : 115
    Points : 139
    Points
    139
    Par défaut Estimer sa bande passante (tcp)
    Salut,

    Je développement actuellement une application de streaming et j'essaye d'utiliser le protocole TCP pour faire passer mes données.
    Vu la nature du protocole (on envoie un paquet et on a un ACK en retour), est-ce possible de savoir si je suis limité en bande passante ?

    Merci d'avance

    PS : vu tout les sous-forum du Réseau j'espère avoir posé ma question au bon endroit ^^'

  2. #2
    Modérateur
    Avatar de Obsidian
    Homme Profil pro
    Développeur en systèmes embarqués
    Inscrit en
    Septembre 2007
    Messages
    7 360
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Développeur en systèmes embarqués
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Septembre 2007
    Messages : 7 360
    Points : 23 600
    Points
    23 600
    Par défaut
    Bonjour,

    Citation Envoyé par Phago Voir le message
    Je développement actuellement une application de streaming et j'essaye d'utiliser le protocole TCP pour faire passer mes données.
    Vu la nature du protocole (on envoie un paquet et on a un ACK en retour), est-ce possible de savoir si je suis limité en bande passante ?
    Non, pas directement, à commencer parce que ta liaison va traverser une succession de réseaux différents dont la capacité maximum sera différente à chaque tronçon, et dépendra du trafic en cours.

    Le seul moyen d'en avoir une idée à peu près fiable est de la mesurer en temps réel et de faire le bilan des paquet transmis/reçus au bout d'une certaine unité de temps.

  3. #3
    Membre habitué
    Homme Profil pro
    Etudiant
    Inscrit en
    Février 2010
    Messages
    115
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : France, Seine Maritime (Haute Normandie)

    Informations professionnelles :
    Activité : Etudiant

    Informations forums :
    Inscription : Février 2010
    Messages : 115
    Points : 139
    Points
    139
    Par défaut
    Citation Envoyé par Obsidian Voir le message
    faire le bilan des paquet transmis/reçus au bout d'une certaine unité de temps.
    Et ce bilan peut être fait côté éméteur seulement, et si oui comment ? Je n'ai pas vraiment le controle du serveur sur lequel j'envoie mes packets

  4. #4
    Membre habitué
    Homme Profil pro
    Etudiant
    Inscrit en
    Février 2010
    Messages
    115
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : France, Seine Maritime (Haute Normandie)

    Informations professionnelles :
    Activité : Etudiant

    Informations forums :
    Inscription : Février 2010
    Messages : 115
    Points : 139
    Points
    139
    Par défaut
    je up vite fait le topic car j'ai vu une application qui marchait pas mal du tout, le mec ne me répond pas à mes mails mais explique sur son blog comment il fait (ça à l'air simple pour lui, pour moi c'est une autre histoire) je cite :

    "I will take the usual approach of using async sockets and monitoring how much data was sent."

    une petite explication ? :')

  5. #5
    Modérateur
    Avatar de Obsidian
    Homme Profil pro
    Développeur en systèmes embarqués
    Inscrit en
    Septembre 2007
    Messages
    7 360
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Développeur en systèmes embarqués
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Septembre 2007
    Messages : 7 360
    Points : 23 600
    Points
    23 600
    Par défaut
    Citation Envoyé par Phago Voir le message
    Je cite :

    "I will take the usual approach of using async sockets and monitoring how much data was sent."

    une petite explication ? :')
    (Presque) littéralement : « j'adopterai l'approche habituelle consistant à utiliser des sockets asynchrones et à mesurer quelle quantité de données a été envoyée ».

    Donc, tu te fixes au départ un laps de temps donné et tu constates à la fin le nombre d'octets effectivement envoyé, et tu en déduis un taux de transfert moyen qui, au final, est bien celui qui t'intéresse quelque soient les considérations techniques entre tes deux points terminaux.

    Sur un réseau TCP/IP et a fortiori sur Internet, tu ne peux pas te baser sur les caractéristiques techniques du médium utilisé pour connaître taux de transfert effectif (par exemple, 100 Mb/s) parce que :

    • Tu vas traverser une série de réseaux successifs différents. Le goulet d'étranglement sera donc le réseau le plus lent de la chaîne ;
    • Tu utilises une liaison par paquets : il y a un overhead fixe qui est donc plus ou moins coûteux en fonction de la taille de ces paquets (il est plus efficace d'envoyer un paquet de mille octets que mille paquets de un octet) ;
    • Le débit du chemin que tu vas emprunter va être fonction du trafic qui y circule déjà (et qui n'est pas le tien) ;
    • Si tu envoies beaucoup de datagrammes (parque ta connectivité immédiate te permet de le faire), alors ces datagrammes peuvent éventuellement emprunter différentes routes pour équilibrer le trafic. Ou pas ;
    • Tes datagrammes peuvent arriver dans le désordre. La pile TCP va alors attendre d'avoir une suite consécutive pour te la transmettre, ce qui va se traduire, au niveau du système, par une petite interruption suivie d'un gros tas de données arrivant en une fois ;
    • Tes datagrammes eux-mêmes peuvent éventuellement être fragmentés, et ces fragments suivre différents chemins, pour arriver dans le désordre.


    Les réseaux IP fonctionnent sur un système « postal » : tu confies une charge utile à ta passerelle la plus proche et cette charge va aller se promener de port en port jusqu'à arriver à destination au bout d'un délai moyen. La seule mesure qui soit donc vraiment fiable à grande échelle est une statistique de la quantité de données effectivement arrivée dans un laps de temps imparti.

  6. #6
    Membre habitué
    Homme Profil pro
    Etudiant
    Inscrit en
    Février 2010
    Messages
    115
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : France, Seine Maritime (Haute Normandie)

    Informations professionnelles :
    Activité : Etudiant

    Informations forums :
    Inscription : Février 2010
    Messages : 115
    Points : 139
    Points
    139
    Par défaut
    Effectivement je comprends un peu mieux
    J'ai passé la journée à me documenter sur le protocole tcp et bien sur sur les socket en C.
    De ce que j'ai compris, il faut créer une socket asynchrone (= non blocante ?) et d'une manière ou d'une autre choper le nombre d'octets reçu par le serveur en 5s ( par exemple ). Ceci étant -j'imagine- possible grâce aux ack envoyé par le serveur à la réception et reçu par mon client.

    Pour ce qui est de la mise en pratique, corrigez moi si je me trompe, j'ai l'impression que serait possible grâce a la fonction select() que j'essaye de bien comprendre à l'aide du man - j'essayerai demain ^^'

    Si j'ai bien compris, avec cette fonction on peut écouter un file descriptor (= socket ?) et connaître son état ( lecture écriture erreur)

  7. #7
    Modérateur
    Avatar de Obsidian
    Homme Profil pro
    Développeur en systèmes embarqués
    Inscrit en
    Septembre 2007
    Messages
    7 360
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Développeur en systèmes embarqués
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Septembre 2007
    Messages : 7 360
    Points : 23 600
    Points
    23 600
    Par défaut
    Citation Envoyé par Phago Voir le message
    De ce que j'ai compris, il faut créer une socket asynchrone (= non blocante ?) et d'une manière ou d'une autre choper le nombre d'octets reçu par le serveur en 5s ( par exemple ). Ceci étant -j'imagine- possible grâce aux ack envoyé par le serveur à la réception et reçu par mon client.
    En fait, tu n'auras pas directement accès à ces ACK au niveau où tu travailles. Il suffit d'envoyer des octets à travers ta connexion comme tu le ferais si c'était un fichier. Si le système ne peut plus transmettre pour quelque raison que ce soit, le socket associé va devenir naturellement bloquant (ou renvoyer EAGAIN, selon l'option que tu as choisie) comme un feu rouge, avant de te laisser reprendre.

    Pour ce qui est de la mise en pratique, corrigez moi si je me trompe, j'ai l'impression que serait possible grâce a la fonction select() que j'essaye de bien comprendre à l'aide du man - j'essayerai demain ^^'
    Si tu n'as qu'un seul socket et que tu ne fais rien à côté, tu peux te contenter de l'ouvrir en mode non bloquant. Sinon, select() est bien l'approche à suivre.

    Si j'ai bien compris, avec cette fonction on peut écouter un file descriptor (= socket ?) et connaître son état ( lecture écriture erreur)
    select() (et ses dérivées : pselect(), poll(), ppoll()…) est un appel qui permet de surveiller plusieurs descripteurs bloquants à la fois (qu'ils soient des descripteurs de sockets, de tubes ou de fichiers ordinaires). Cet appel est lui-même bloquant et se débloque dès qu'au moins l'un d'eux cesse de l'être.

    C'est nécessaire pour pouvoir surveiller plusieurs connexions à la fois car autrement, dès que l'on resté bloqué sur l'une d'entre elles, on ne peut pas savoir si d'autres sont exploitables avant que celle-ci en particulier se soient réveillée, sauf à passer tous les descripteurs en non-bloquant et faire de l'attente active, ce qui n'est évidemment pas souhaitable.

  8. #8
    Membre habitué
    Homme Profil pro
    Etudiant
    Inscrit en
    Février 2010
    Messages
    115
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : France, Seine Maritime (Haute Normandie)

    Informations professionnelles :
    Activité : Etudiant

    Informations forums :
    Inscription : Février 2010
    Messages : 115
    Points : 139
    Points
    139
    Par défaut
    Citation Envoyé par Obsidian Voir le message
    Si tu n'as qu'un seul socket et que tu ne fais rien à côté, tu peux te contenter de l'ouvrir en mode non bloquant. Sinon, select() est bien l'approche à suivre.
    Hihi merci, j'ai réussis à m'en sortir avec select
    Par contre sans ce fameux select(), mon send() me renvoi 0 si je passe le socket en non bloquant

  9. #9
    Modérateur
    Avatar de Obsidian
    Homme Profil pro
    Développeur en systèmes embarqués
    Inscrit en
    Septembre 2007
    Messages
    7 360
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Développeur en systèmes embarqués
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Septembre 2007
    Messages : 7 360
    Points : 23 600
    Points
    23 600
    Par défaut
    Citation Envoyé par Phago Voir le message
    Hihi merci, j'ai réussis à m'en sortir avec select
    Par contre sans ce fameux select(), mon send() me renvoi 0 si je passe le socket en non bloquant
    C'est curieux. Sur un recv(), ça aurait posé problème. Sur un send(), on peut considérer que tu as envoyé zéro octet mais ça aurait quand même dû renvoyer EAGAIN ou EWOULDBLOCK.

    Il faudrait que l'on voie ton code pour en savoir plus.

  10. #10
    Membre habitué
    Homme Profil pro
    Etudiant
    Inscrit en
    Février 2010
    Messages
    115
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : France, Seine Maritime (Haute Normandie)

    Informations professionnelles :
    Activité : Etudiant

    Informations forums :
    Inscription : Février 2010
    Messages : 115
    Points : 139
    Points
    139
    Par défaut
    pas de soucis
    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
     
    void connect()
    {
       struct sockaddr_in spls;
       spls.sin_family = AF_INET;
       spls.sin_port = htons(1935);
       inet_aton(_ip, &spls.sin_addr);
       // Non bloking socket
       fcntl(_sockfd, F_SETFL, fcntl(_sockfd, F_GETFL) | O_NONBLOCK);
       if((sockfd = socket(AF_INET,SOCK_STREAM,0)) < 0){
          perror("sock desc failed");
       }
       struct timeval tv;
       tv.tv_sec = 5; /* 5 Secs Timeout */
       tv.tv_usec = 0; // Not init'ing this can cause strange errors
       setsockopt(_sockfd, SOL_SOCKET, SO_RCVTIMEO, (char *)&tv,sizeof(struct timeval));
       int n = 1;
       // ignore broken pipe
       setsockopt(self->_sockfd, SOL_SOCKET, SO_NOSIGPIPE, (void *)&n, sizeof(n));
     
       // Naggle on/off
       //setsockopt(_sockfd, IPPROTO_TCP, TCP_NODELAY, (void*)&n, sizeof(n));
     
       if(connect(_sockfd, (struct sockaddr*)&spls, sizeof(struct sockaddr)) < 0){
          perror("connect rtcp announce failed");
       }
    }
     
    // et pour la partie envoi/monitoring :
     
    if( (x=send(_sockfd,finalPacket,cBytes,0) < 0))
    {
       perror("fail sending v_packet");
    }
     
    fd_set fdWrite;
    FD_ZERO(&fdWrite);
    FD_SET(_sockfd, &fdWrite);
    int retVal = select(_sockfd+1, NULL, &fdWrite, NULL, NULL);
    if(retVal==1)
    {
       effective_bitrate += cBytes;
    }
    J'en profite pour ajouter que c'est une application temps réel (live streaming) et que j'ai 2 petites questions:
    - Le TCP_NODELAY vaut il le coup ? (à priori vu que je cherche à maximiser ma bande passante je pense que non...)
    - Es-ce que ça vaudrait le coup de faire un mini benchmark de 2-3s avant de commencer à envoyer des paquets histoire de pas taper dans un envoi à 1Mb/s (réseau 4g) alors que ma bande passante est de 300kb/s (réseau 3g)
    Dans le cas d'une réponse négative, faut il essayer de couper temporairement mes send() pour essayer de récupérer un délai décent ?

  11. #11
    Modérateur
    Avatar de gangsoleil
    Homme Profil pro
    Manager / Cyber Sécurité
    Inscrit en
    Mai 2004
    Messages
    10 148
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Savoie (Rhône Alpes)

    Informations professionnelles :
    Activité : Manager / Cyber Sécurité

    Informations forums :
    Inscription : Mai 2004
    Messages : 10 148
    Points : 28 113
    Points
    28 113
    Par défaut
    Bonjour,

    Pourquoi utiliser TCP pour faire du streaming ? Je ne dirai pas que c'est ce que tu peux faire de pire, mais ce n'est clairement pas adapté !

    Regarde du cote de RTP/RTCP, c'est un protocole qui est beaucoup plus adapte a tes besoins.
    "La route est longue, mais le chemin est libre" -- https://framasoft.org/
    Les règles du forum

  12. #12
    Membre habitué
    Homme Profil pro
    Etudiant
    Inscrit en
    Février 2010
    Messages
    115
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : France, Seine Maritime (Haute Normandie)

    Informations professionnelles :
    Activité : Etudiant

    Informations forums :
    Inscription : Février 2010
    Messages : 115
    Points : 139
    Points
    139
    Par défaut
    Justement j'ai développé un client assez complet RTSP qui était d'abord en UDP - je suis sur le projet depuis déjà 6 mois - Et justement je suis en train de migrer vers TCP RTP

    Les raisons pour lesquelles tout est développé en TCP actuellement (TCP RPT, RTMP, HTTP, et je pense que le WebRTC le sera aussi ^^') c'est que les bandes passantes sont bien meilleures qu'avant, et surtout avec le codec standard du moment (le h.264), une perte de packet de 1% s'avère fatale pour la qualité de la vidéo, autant en live qu'en replay, surtout si tu regarde la vidéo sur safari/iOS.

    De plus si tu veux t'adapter à la bande passante tu doit t'aider des packets RTCP (RR) qui ne font que rapporter... le taux de "packet loss" qui te garanti donc des premières secondes assez trash visuellement. Enfin, le problème c'est que mon codec est VBR (variable bitrate) ce qui fait qu'il va parfois envoyer des packets un peu trop gros - causant une latence à la réception des paquets suivant - et si cette latence est trop grande le serveur sera obliger de drop des packets pour rester "dans le timming"

Discussions similaires

  1. Serveur dedié et bande passante ?
    Par ShinJava dans le forum Hébergement
    Réponses: 9
    Dernier message: 03/06/2005, 11h29
  2. [Stratégie] Limiter la bande passante
    Par Neuromancer dans le forum Développement
    Réponses: 7
    Dernier message: 17/01/2005, 16h29
  3. Appication Client/serveur : Limiter la bande passante ?
    Par souch dans le forum Web & réseau
    Réponses: 8
    Dernier message: 25/07/2004, 15h53
  4. Limiter la bande passante
    Par naili dans le forum Réseau
    Réponses: 3
    Dernier message: 15/01/2004, 09h21
  5. [Bande passante]
    Par Alexr dans le forum Développement
    Réponses: 7
    Dernier message: 12/09/2003, 15h36

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo