Discussion :

[stalacta]

Bonjour à tous !

Je suis sur un programme d'audio-conférence en python 3 à 2 ou plus au travers internet (j'ai donc ouvert un port sur mon routeur) et je suis confronté à un problème : il s'écoule 6 secondes entre le moment où je parle et le moment où j'entends la réponse, c'est beaucoup trop. Aussi je me demandais s'il était possible de diminuer ce temps en changeant de protocole (j'utilise un socket de base avec le module socket, je ne connais que ce qu'on voit dans les tutos de base). Le but serait d'envoyer un paquet de données par frame d'un peu plus de 500 octets (19,5 frames par seconde) à une vitesse raisonnable au travers le réseau. Je dois aussi pouvoir mettre plusieurs destinataires pour le même paquet (avec le protocole que j'utilise, pour envoyer 100 octets à 2 personnes, je dois ouvrir deux connexions et envoyer 200 octets au total alors que je voudrais envoyer seulement 100 quel que soit le nombre de destinataires).

Question subsidiaire : Si vous savez comment je pourrais envoyer des données directement d'un ordinateur à l'autre sans avoir à ouvrir un port sur ma livebox, comme skype ou hamachi semble le faire, je suis preneur !

Merci d'avance !

[deusyss]

Salut,

Je me suis jamais attaqué à ce genre de chose, je ne suis donc pas sur d'etre d'une grande aide, mais apres quelque recherche j'ai trouvé des choses comme pyaudio, pyspeex, timeside. As tu déjà regardé ce genre de chose?

Concernant ta question subsidiaire, aucune idée . Pour moi, la livebox fait routeur, et si tu n'utilise pas les ports classiques dédiés, il faut les ouvrir. Mais en interne, entre poste, normalement, tu ne dois pas avoir de firewall si?

[stalacta]

Alors oui, bien sûr ma livebox contient le routeur. En réseau local, aucun problème, très haut débit, transmission directe sur n'importe quel port... mais ça ne nous avance pas loin de le faire dans la même maison ^^. Je n'ai pas tenté sur le port 80, peut-être que je n'aurais pas besoin de configurer ma livebox/routeur. Sinon, j'utilise déjà pyaudio pour capturer le son. Pour ce qui est du protocole, j'ai effectué quelques recherches et peut-être que de l'UDP pourrait m'être utile. A voir selon ce que je trouve sur ça.

[wiztricks]

Salut,

Lorsque vous démarrez un client Skype sur un PC, il se connecte à un serveur internet (une adresse IP fixe)
Ce serveur fera la médiation entre les utilisateurs. Comme, in fine, les demandes seront traitées par le "client", pas besoin de trafiquer votre box pour fabriquer un "service" accessible via l'adresse IP (presque) fixe de la box et la router vers un "serveur" démarré sur votre PC.

Pour les autres questions, je vous ai déjà répondu dans d'autres posts.

- W

[stalacta]

Bonjour,

J'avais regardé et il semblerait qu'avec Skype, pour prendre l'exemple le plus connu, il y en en effet une connexion entre le serveur Skype (ip fixe, serveur configuré pour router toutes les demandes) et les client mais juste pendant la période d'identification. Pour ce qui est des IPs non fixes des utilisateurs, cela ne pose en effet pas de problème dans la mesure où on a ce serveur. Mais le reste est fait directement entre les utilisateur, si j'ai bien compris ce schéma et ces explications.. En configurant le logiciel, il me semble par ailleurs qu'il peut être configuré pour sélectionner les ports que l'on doit ouvrir. Pour ce qui est des autres réponses, j'avais regardé mais le module de VLC était totalement imbuvable sans documentation appropriée (et j'ai cherché) ; mon niveau en anglais est acceptable mais j'imagine que vous comprenez à quel point il est désespérant de lire toutes les docstrings (et encore, quand les fonctions/classes sont documentées !) d'un code source de beaucoup de lignes, en anglais qui plus est... Pour les autres, un peu plus difficile à trouver mais j'ai compris le principe général de la compression etc.
Je me suis donc débrouillé un peu tout seul sans penser au protocole réseau, je me suis alors documenté quand j'ai vu le problème et j'ai compris que j'utilisais du TCP alors que pour ce type de projet, il vaut mieux utiliser de l'UDP.
J'ai testé mon programme en conditions réelles en remplaçant juste connexion_principale = socket(AF_INET, SOCK_STREAM) par connexion_principale = socket(AF_INET, SOCK_DGRAM) et ça a planté quand j'ai voulu mettre listen, tout est donc à reprogrammer niveau envoi des données... C'est pourquoi avant tout cela je veux être sûr que c'est la bonne solution : Est-ce une bonne solution d'utiliser de l'UDP ?

Merci de vos réponses et merci d'avance pour les prochaines.

[fred1599]

Le protocole UDP intervient quand le temps de remise des paquets est prédominant. Il est plus simple que le protocole TCP, il est non fiable, pas de contrôle de flux, pas de conservation de l'ordre de remise des paquets... Il est plus rapide que TCP

La transmission de la voix est une utilisation du protocole UDP, car l'inversion de l'ordre n'altère pas la compréhension du message final.

[stalacta]

Merci, j'ai donc la confirmation que l'UDP est le plus adapté. Je mets résolu, cependant si vous avez une réponse à la "question subsidiaire", je suis preneur !

[wiztricks]

La transmission de la voix est une utilisation du protocole UDP, car l'inversion de l'ordre n'altère pas la compréhension du message final.

A condition que le récepteur ait essayé de remette les "trames" dans l'ordre.
Ce qui implique qu'il devra "bufferiser" un certain temps la trame N tant qu'il n'aura pas reçu N-1.
Si la trame N-1 arrive assez tôt, il pourra vider N-1 et N sur la carte son.

Coté "code", c'est beaucoup plus compliqué...
Et si c'est ce qu'on veut, RTP=(real time protocol) est déjà dispo.

- W

[stalacta]

Ah, ça peut être intéressant... le RTP est implémenté en Python avec socket ? ou il faut télécharger quelque chose.

[wiztricks]

Ah, ça peut être intéressant... le RTP est implémenté en Python avec socket ? ou il faut télécharger quelque chose.

Les choses systèmes (comme un protocole réseau) se codent avec des langages systèmes.
Après on prend regarde les implémentations qui tiennent la route, celles qui ont un binding Python, on teste,...

- W