Estimer sa bande passante (tcp)

Version imprimable

13/12/2013, 19h09
Phago

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 ^^'
13/12/2013, 19h50
Obsidian

Bonjour,

Citation:

Envoyé par Phago

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.
13/12/2013, 20h13
Phago

Citation:

Envoyé par Obsidian

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
16/12/2013, 15h48
Phago

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 ? :')
16/12/2013, 21h24
Obsidian
Citation:

Envoyé par Phago

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.
17/12/2013, 01h39
Phago

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)
17/12/2013, 13h11
Obsidian

Citation:

Envoyé par Phago

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.

Citation:

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.

Citation:

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.
17/12/2013, 14h58
Phago

Citation:

Envoyé par Obsidian

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 :D
Par contre sans ce fameux select(), mon send() me renvoi 0 si je passe le socket en non bloquant
17/12/2013, 17h09
Obsidian

Citation:

Envoyé par Phago

Hihi merci, j'ai réussis à m'en sortir avec select :D
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.

pas de soucis :)
Code:

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 ?

18/12/2013, 08h42
gangsoleil

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.
18/12/2013, 11h13
Phago

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"