Echange de fichier vidéo via une socket

Version imprimable

06/01/2010, 21h04
clemnantes

Echange de fichier vidéo via une socket

Bonjour à tous,
Alors voilà je me met depuis peu à la programmation réseau pour un projet dans ce but j'ai réalisé deux programme un client et un serveur qui s'échangent des fichier.
Dans un but évident il faudrait que les fichiers transmis et/ou reçus soit de n'importe quels types or avec un fichier type .txt aucun problème:D mais quand j' essaye avec un fichier vidéo (.avi par exemple) déjà il ne transfert pas tou le fichier (en moyenne il manque environ 30Mo) et sur la vidéo je ne parvien à lire que les 15 premières secondes sur le fichier transferé.
j'utilise un flux de type FILE* pour transférer les donnés et j'ai beau chercher je ne trouve que des tuto pour le transfert de simple chaine de charactère Alors si quelqu'un a un tuyau merci beaucoup.

PS : l'application est sensé tourné sur un noyau unix
06/01/2010, 21h19
ram-0000

On peut voir le code de l'ouverture du fichier ?

Bien sur,
La construction de l'adresse a contacter est faite dans lecture argument et de ce côter je suis sur de moi.

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
44
45
int client(int argc , char ** argv){
int sock , nb_lu;
FILE *entree;
struct sockaddr_in adresse;
char buffer[LG_BUFFER];
char path[1024];
 
if(lecture_argument(argc, argv, &adresse , "udp")<0) exit(EXIT_FAILURE);
 
adresse.sin_family = AF_INET;
 
if((sock = socket(AF_INET, SOCK_DGRAM ,0))<0){
perror("erreur socket");
exit(EXIT_FAILURE);
}
 
printf("donner le chemin du fichier\n");
scanf("%s",path);
 
if((entree = fopen(path,"r+")) == NULL){
perror("erreur d'ouverture fichier");
exit(EXIT_FAILURE);
}
 
printf("début de transmission\n");
 
while((nb_lu = fread(&buffer,sizeof(char),LG_BUFFER,entree)) , !feof(entree)){
 
if(nb_lu<0){
perror("erreur de fread");
break;
}
 
//printf("octet transmis : %X\n",buffer);
 
 
sendto(sock,&buffer,LG_BUFFER,0,
(struct sockaddr *) &adresse,sizeof(struct sockaddr_in));
}
printf("fin de transmission\n");
fclose(entree);
close(sock);
 
return EXIT_SUCCESS;
}

06/01/2010, 23h18
Melem
Déjà faire un transfert de fichier en UDP est une très mauvaise idée étant donné qu'avec :
Code:

1 2 sendto(..., data1, ...); sendto(..., data2, ...);
Il n'est nullement garanti que data1 parviendra à la destination avant data2. Il FAUT utiliser TCP. Mais ce n'était pas là ton problème et j'en doute d'ailleurs qu'elle provient du client. Moi, c'est le code du récepteur qui m'intéresse. Tu as sûrement commis l'erreur classique à savoir penser que :

Code:

recv/recvfrom (..., buffer, sizeof(buffer), ...);

Lit sizeof(buffer) octets. Pourtant, c'est juste une demande de lire AU PLUS sizeof(buffer) octets. Dès que des données sont disponibles, elles seront retournées. Lire la valeur de retour de la fonction pour connaître le nombre d'octets lus.

Du côté du fichier, il faut ouvrir en mode "rb" dans l'émetteur (pour lire) et en "wb" dans le récepteur (pour écrire).

Ensuite, tu devrais changer ton fread en :

Code:

fread(buffer, 1, LG_BUFFER, entree);

En effet, l'ancien code suppose que tout fichier doit être de taille multiple de LG_BUFFER.

Il faudra également réécrire la boucle parce qu'elle n'est pas très "sécurisée".

Fais les modifs et poste le code du client ET le code du serveur la prochaine fois que tu repasseras.
07/01/2010, 08h34
Jenna

Citation:

Envoyé par Melem

Déjà faire un transfert de fichier en UDP est une très mauvaise idée

Outre le fait que le séquencement n'est pas garanti par le protocole, il faut ajouter aussi que le protocole UDP ne garantit pas la réception des paquets envoyés.

Il se peut que ton émetteur envoie des paquets, que le écepteur ne les recoive pas et que personne n'en sache rien (d'où peut être tes octets manquants à l'appel).
07/01/2010, 11h09
BSans
Pour ce type de transferts, j'aurai également eu plutôt tendance a utiliser un flux binaire :
Code:

1 2 FILE *fd = fopen("mon_fichier","rb");
07/01/2010, 13h31
Melem

Citation:

Envoyé par Jenna

Outre le fait que le séquencement n'est pas garanti par le protocole, il faut ajouter aussi que le protocole UDP ne garantit pas la réception des paquets envoyés.

Il se peut que ton émetteur envoie des paquets, que le récepteur ne les reçoive pas et que personne n'en sache rien (d'où peut être tes octets manquants à l'appel).

Mouaip.

Citation:

Envoyé par BSans

Pour ce type de transferts, j'aurai également eu plutôt tendance a utiliser un flux binaire :

Code:

FILE *fd = fopen("mon_fichier","rb");

C'est pas du plagiat ça ?

Citation:

Envoyé par Melem

Du côté du fichier, il faut ouvrir en mode "rb" dans l'émetteur (pour lire) et en "wb" dans le récepteur (pour écrire).

Lol.
07/01/2010, 14h23
BSans

Au temps pour moi, j'ai sauté cette ligne dans ma lecture un peu précipitée :?

Mais ça ne fait qu'appuyer le fait d'utiliser un flux binaire :)

Bonsoir,
Déjà merci à tous pour vos réponse rapide.
Pour ce qui est de l'utilisation du TCP en lieu et place de l'UDP j'y avais déjà penser mais cette application devra à la longue s'inscrire dans un dispositif de broadcast d'ou UDP.
Sinon voila le code modifié plus le code coté serveur :

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
int client(int argc , char ** argv){
  int	sock , nb_lu;
  FILE *entree;
  struct sockaddr_in adresse;
  char	buffer[LG_BUFFER];
  char path[1024];
 
  if(lecture_argument(argc, argv, &adresse , "udp")<0) exit(EXIT_FAILURE);
 
  adresse.sin_family = AF_INET;
 
  if((sock = socket(AF_INET, SOCK_DGRAM ,0))<0){
    perror("erreur socket");
    exit(EXIT_FAILURE);
  }
 
  printf("donner le chemin du fichier\n");
  scanf("%s",path);
 
  if((entree = fopen(path,"rb")) == NULL){
    perror("erreur d'ouverture fichier");
    exit(EXIT_FAILURE);
    }
 
  printf("début de transmission\n");
 
  while((nb_lu = fread(buffer,1,LG_BUFFER,entree))<0 , !feof(entree)){
 
    //printf("octet transmis : %X\n",buffer);
 
 
    sendto(sock,&buffer,nb_lu,0,
	   (struct sockaddr *) &adresse,sizeof(struct sockaddr_in));
  }
  printf("fin de transmission\n");
  fclose(entree);
  close(sock);
 
  return EXIT_SUCCESS;
}

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
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
int serveur (int argc, char * argv[])
{
int sock;
FILE * sortie;
struct sockaddr_in adresse;
char buffer[LG_BUFFER];
int nb_lus , i;
char path[1024];
 
 
  if (lecture_argument(argc, argv, & adresse, "udp") < 0) exit(EXIT_FAILURE);
 
  adresse.sin_family = AF_INET;
 
  if ((sock = socket(AF_INET, SOCK_DGRAM, 0)) < 0) {
    perror("socket");
    exit(EXIT_FAILURE);
  }
 
  if (bind(sock,(struct sockaddr*) & adresse, sizeof(struct sockaddr_in)) < 0) {
    perror("bind");
    exit(EXIT_FAILURE);
  }
 
 
  printf("donner le chemin du fichier\n");
  scanf("%s",path);
 
  if((sortie = fopen(path,"wb")) == NULL){
	  perror("erreur d'ouverture fichier");
	  exit(EXIT_FAILURE);
	}
 
  printf("début de réception\n");
 
    while((nb_lus = recv(sock, buffer, LG_BUFFER, 0))>0){
 
 
 
      if (nb_lus < 0) {
	perror("reception");
	break;
      }
 
      if(nb_lus == 0)break;
 
      //printf("octet reçus : %X , %c\n",buffer,buffer);
 
      if(buffer){fwrite(&buffer, 1, nb_lus,sortie);
		}
 
      if(fflush(sortie)==EOF){
	perror("erreur d'écriture disque ");
	exit(EXIT_FAILURE);
      }
 
 
    }
 
  printf("fin de réception\n");
  close(sock);
  fclose(sortie);
 
return EXIT_SUCCESS;
}

Voila je n'ai cependant pas réécris la boucle de l'émetteur car je ne voit pas ce qui n'est pas sécurisée pourrait tu être plus explicite?
(je ne demande pas que tu fasse mon boulot juste quelque explication)

08/01/2010, 09h14
Jenna
Une remarque concernant le code (dans ton serveur et ton client) :
Code:

1 2 3 sendto(sock,&buffer,nb_lu,0, (struct sockaddr *) &adresse,sizeof(struct sockaddr_in)); if(buffer){fwrite(&buffer, 1, nb_lus,sortie);
Il faudrait enlever le & avant le buffer, il ne sert à rien et il embrouille la lecture.

Sinon, le protocole que tu mets en place n'est absolument pas sûr.

Tu utilises UDP et UDP ne garantit ni le séquencement des paquets ni leur acheminement. Tu peux perdre des paquets sans le savoir ou recevoir des paquets dans un mauvais ordre. C'est pour cela que l'on te dit de passer en TCP.

Autre chose, tu ne gères absolument pas le cas où 2 clients se connectent à ton serveur. Le recv() que tu fais dans le serveur devrait être remplacé par un recvfrom() afin de tester si le paquet que tu reçois provient bien du même émetteur.
08/01/2010, 11h49
Mac LAK
Citation:

Envoyé par Jenna

Tu utilises UDP et UDP ne garantit ni le séquencement des paquets ni leur acheminement. Tu peux perdre des paquets sans le savoir ou recevoir des paquets dans un mauvais ordre. C'est pour cela que l'on te dit de passer en TCP.

Par rapport au besoin initial (transfert vidéo, en flux je suppose ?), et ceci en multi-client, c'est UDP qu'il faut utiliser... Mais pas "brut de fonderie", bien sûr.

Il faut numéroter chaque paquet (ex : numéro de trame, correspondant au numéro d'image), et être certain que le flux vidéo ne requiert JAMAIS un paquet précédent pour être décodé et affiché (ex : ne jamais transférer une trame sur plus d'un paquet UDP, identifier clairement les trames de référence, etc.). L'idéal est d'utiliser un timestamp, qui te permettra également de tenir compte du nombre d'images par seconde de façon à maintenir une vitesse d'affichage correcte même s'il manque des images.

Par exemple, à 25 FPS, ton timestamp s'incrémente de 40 ms à chaque image. Si tu vois que tu décodes trop lentement et que tu prends du retard, alors tu peux facilement jeter quelques paquets pour rattraper le temps perdu. Inversement, si tu tentes de reconstruire au mieux le flux vidéo (en attendant une trame N alors que tu as déjà la N+1, par exemple), cela te permet de savoir s'il est pertinent de continuer à attendre ou pas.

Ainsi, ton client peut agir sereinement :
- S'il reçoit un paquet plus ancien que le dernier reçu, le paquet est jeté sans autre forme de procès.
- S'il manque des paquets, le flux vidéo s'interrompt, bien sûr, mais reprendra dès que possible (effet "image gelée" pendant un instant).
- UDP garantit par contre que SI le paquet arrive, alors il est intègre : donc, pas de risques d'images corrompues, mais seulement d'images dans le mauvais ordre et/ou manquantes.
Attention, si tu transmets un flux MPEG : il faudra clairement et correctement gérer les images de références (Frames I et DC) et les images prédictives (Frames B et P) de façon à ne pas risquer des interruptions lourdes du flux dans le cas de perte de plusieurs trames de référence consécutives. Bien que beaucoup plus coûteux en bande passante, un codage MJPEG pourrait être préférable pour pallier ce problème.

Si par contre, tu dois garantir l'intégrité des données reçues (ordre et complétude des données), alors il te faudra prévoir un système d'acquittement de la part des clients, de façon à savoir si oui ou non tu dois réémettre certains paquets. Cela peut être également une demande explicite du client (ex : par un canal TCP/IP), à qui tu renverras explicitement les données manquantes sans les diffuser à nouveau en broadcast. Dans tous les cas, tu vas te retrouver à devoir faire, peu ou prou, la même chose que ce que fait TCP. Tu ne gagneras qu'au niveau du broadcast : cela peut être rentable avec beaucoup de clients sur un réseau LAN, mais il serait étonnant que ça le soit sur le net avec peu de clients (où, dans ce cas, TCP montrera une très nette supériorité sur ton UDP bricolé).
09/01/2010, 11h27
clemnantes

tu m'as dit :
Il faut numéroter chaque paquet (ex : numéro de trame, correspondant au numéro d'image), et être certain que le flux vidéo ne requiert JAMAIS un paquet précédent pour être décodé et affiché

Je fais cela simplement en ajoutant une structure contenant le TimeStamp et le numéro du paquet lors de la transmition, MAIS pour la récupération de paquet perdus cela implique que la méthode découpant le fichier d'origine doit également sauvegarder les paquets envoyer sur le disque de la machine émétrice pour pouvoir les renvoyer? C'est- bien cela?:koi:

Sinon, J'aurais une autre question : est-ce qu'il existe une norme sur les signaux de fin de transmition ou est ce que je peut en inventer un? (Par exemple pour signaler au serveur que le fichier transmis est finis car pour l'instant lorsque cela arrive je n'ai d'autre choix que de l'arrêter avec un gros CTRL+C :aie: c'est pas très propre pour le relachement de la mémoire)
09/01/2010, 14h46
Melem

Citation:

Sinon, J'aurais une autre question : est-ce qu'il existe une norme sur les signaux de fin de transmission ou est ce que je peut en inventer un? (Par exemple pour signaler au serveur que le fichier transmis est finis car pour l'instant lorsque cela arrive je n'ai d'autre choix que de l'arrêter avec un gros CTRL+C c'est pas très propre pour le relachement de la mémoire)

En binaire c'est impossible, il faut prévenir à l'avance le récepteur de la taille du fichier à envoyer. Si les données à envoyer sont du texte, alors on peut inventer tout un tas de marqueur de fin (puisqu'il existe de nombreux codes qui ne sont attribués à aucun caractère "normal" : NUL, ESC, etc.). Toujours dans ce même cas, on peut envoyer es données ligne par ligne, comme avec les protocoles applicatifs de l'Internet (HTTP, SMTP, etc.). Ces protocoles utilisent la séquence CRLF ('\r' suivi de '\n') comme marqueur de fin de ligne.
11/01/2010, 11h04
Mac LAK

Citation:

Envoyé par clemnantes

Je fais cela simplement en ajoutant une structure contenant le TimeStamp et le numéro du paquet lors de la transmition, MAIS pour la récupération de paquet perdus cela implique que la méthode découpant le fichier d'origine doit également sauvegarder les paquets envoyer sur le disque de la machine émétrice pour pouvoir les renvoyer? C'est- bien cela?:koi:

Oui et non : tu peux aussi avoir une règle simple permettant de la retrouver immédiatement dans le fichier d'origine (ex : si le fichier d'origine contient déjà un compteur de trames, par exemple). Le but n'est pas de sauvegarder les trames émises, car ce serait trop coûteux en temps, mais de savoir les reconstruire à la demande... Comme les retransmissions ne sont normalement pas prioritaires, tu peux par exemple avoir un thread basse priorité qui s'en occupe.

Ceci étant dit, un BC servant à un simili-FTP n'est pas forcément une excellente idée, plusieurs te l'ont déjà dit : c'est une technologie adaptée à une diffusion en streaming, où la perte de quelques trames n'est pas critique, et non pas à un transfert ordonné et complet de données volumineuses.
En effet, suivant la qualité du réseau, tu peux mettre plus de temps à transférer un gros fichier sur plusieurs postes en UDP que transférer N fois en TCP/IP ! ;)

Citation:

Envoyé par clemnantes

Sinon, J'aurais une autre question : est-ce qu'il existe une norme sur les signaux de fin de transmition ou est ce que je peut en inventer un? (Par exemple pour signaler au serveur que le fichier transmis est finis car pour l'instant lorsque cela arrive je n'ai d'autre choix que de l'arrêter avec un gros CTRL+C :aie: c'est pas très propre pour le relachement de la mémoire)

En général, on implémente soit quelque chose du genre "Dernière trame, déconnexion" qui sera un paquet spécifique et reconnaissable indiquant la fin de transmission, soit on transfère une taille des données de façon préliminaire. Dans tous les cas, cela demande un entête de trame permettant de distinguer les cas.

Il vaut mieux prévenir que guérir, et prévoir le tout : taille prévue des données globales, taille unitaire de chaque paquet, numéros de reconstruction des paquets, et un paquet de fin de transmission (ex : interruption de la diffusion par le serveur sur demande explicite, comme un arrêt de la machine). Bien entendu, il te faut prévoir un système d'acquittement également, et tu peux t'inspirer du principe de TCP qui est d'acquitter les données par bloc. Une fois que tous les clients ont acquitté un paquet N, il n'est alors plus nécessaire de conserver en mémoire les données des paquets 0..N car TOUS les clients les ont reçus.
04/02/2010, 14h24
clemnantes

Bonjour tou le monde
Sa fais un bout de temps que je ne suis pas venu,
Je voulais juste dire que mon soucie était résolu,
Au final l'application fais un mix entre UDP et TCP
Merci à tous pour votre aide