Socket et envoi d'images ???

Socket et envoi d'images ??? - C - Programmation

Marsh Posté le 17-11-2005 à 00:21:24    

Bonjour, c encore moi :)
 
j'vai essayer de faire simple, je fais un projet de socket, j'ai aucun problem pour transmetre une page HTML dispo sur mon serveur a un client, mais le pb c'est quand y a une image, celle si n'est pas visible sur le client si il utilise un navigateur, et elle est sous forme de caractères très etranges si j'utilise une commande Telnet. Donc ma question est la suivante:
   Quel est la syntax correct pour lire une image, et l'ecrire de l'autre coté ?
 
voila comment je lis les fichiers pour l'instant:
     
Coté serveur (vraiment siplifié  ;)  )
 

Code :
  1. fichier_a_envoyer=fopen(nomDuFichier,"r" );          //on lis le fichier a envoyer
  2.          fichier_socket=fdopen(idSockDialogueClient,"w" );   //Socket en ecriture
  3. while(fgets(chaine,1000,fichier_a_envoyer)!=NULL)  /* on recopie 1000 caractère par 1000 cara et on  
  4. les envois */
  5.   {
  6.   fprintf(fichier_socket,"%s\n",chaine); 
  7.   fflush(fichier_a_envoyer);
  8.   }


 
j'ai pensé a remplacé le r et w  par rb et wb, mais apparament c pareil le pb vient peut etre du formatage ( je precise que l'extension est bien celle d'une image coté client).
 
une idée? merci ciao

Reply

Marsh Posté le 17-11-2005 à 00:21:24   

Reply

Marsh Posté le 17-11-2005 à 09:33:26    

fgets c'est normalement fait pour un fichier texte. Une image est un fichier binaire (ouvrir avec "rb"/"wb" si je me rappelle bien), et à lire/ecrire avec fread/fwrite.


---------------
-( BlackGoddess )-
Reply

Marsh Posté le 17-11-2005 à 10:41:08    

blackgoddess a écrit :

Une image est un fichier binaire (ouvrir avec "rb"/"wb" si je me rappelle bien)...


Pas nécessaire de préciser "b" sur Unix. En revanche, l'idée de creuser "fgets" est intéressante car fgets arrête sa lecture à chaque '\n' (caractéristique d'une ligne dans un fichier texte). Or, des '\n', il peut y en avoir des tas sur une image mais ils ne signifient rien de particulier.
 

marcmm13 a écrit :

j'ai pensé a remplacé le r et w  par rb et wb, mais apparament c pareil le pb vient peut etre du formatage ( je precise que l'extension est bien celle d'une image coté client).


L'extension ne conditionne pas le type de fichier, c'et juste un repère permettant au système de choisir le programme le mieux approprié pour ouvrir ledit fichier. Mais si je renomme "toto.doc" en "toto.jpg", cela n'en fera pas une image pour autant !!!
 

marcmm13 a écrit :

une idée? merci ciao


Essaye de ramener sur ton serveur avec un média quelconque (disquette, clef USB, ftp) ton image reçue chez le client... et compare là (cmp) avec l'image d'origine. S'il y a une différence même sur un seul octet, c'est que ça vient de ton transfert (fgets ???).
Au fait, ton client est-il Unix ou Windows ???


Message édité par Sve@r le 17-11-2005 à 10:52:43

---------------
Vous ne pouvez pas apporter la prospérité au pauvre en la retirant au riche.
Reply

Marsh Posté le 17-11-2005 à 12:41:39    

Merci de vos réponses
 

Citation :

Au fait, ton client est-il Unix ou Windows ???


 
-->unnix.
 
j'avais pas pensé au fgets, sije fais un fread vous pensez que c'est bon?? je test et je vous dis

Code :
  1. fichier_a_envoyer=fopen(nomDuFichier,"r" );          //on lis le fichier a envoyer  
  2.          fichier_socket=fdopen(idSockDialogueClient,"w" );   //Socket en ecriture  
  3.     while(fread(chaine,1000,fichier_a_envoyer)!=NULL)  /* on recopie 1000 caractère par 1000 cara et on   
  4. les envois */
  5.             {
  6.             fprintf(fichier_socket,"%s\n",chaine);   
  7.             fflush(fichier_a_envoyer);
  8.             }


Citation :

Essaye de ramener sur ton serveur avec un média quelconque (disquette, clef USB, ftp) ton image reçue chez le client... et compare là (cmp) avec l'image d'origine. S'il y a une différence même sur un seul octet, c'est que ça vient de ton transfert (fgets ???).  


Ils ne sont pas identiques en tout points :/
 

Reply

Marsh Posté le 17-11-2005 à 12:57:44    

fwrite, pas fprintf (ton fichier peut contenir des octets à 0)
et pense à gérer que la taille du fichier n'est pas forcement un multiple de 1000.


---------------
-( BlackGoddess )-
Reply

Marsh Posté le 17-11-2005 à 13:34:41    

marcmm13 a écrit :

j'avais pas pensé au fgets, si je fais un fread vous pensez que c'est bon??


Certainement

marcmm13 a écrit :

Ils ne sont pas identiques en tout points :/


Alors ca vient bien de toi
 

marcmm13 a écrit :

Code :
  1. while(fread(chaine,1000,fichier_a_envoyer)!=NULL)  /* on recopie 1000 caractère par 1000 cara et on   
  2. les envois */
  3.             {
  4.             fprintf(fichier_socket,"%s\n",chaine);   
  5.             fflush(fichier_a_envoyer);
  6.             }



 
Bon, déjà fread attend 4 paramètres et non 3... et en plus il renvoie le nb d'éléments lus ou 0 quand c'est fini mais pas NULL
 

Code :
  1. size_t nb_lu;
  2.     while((nb_lu=fread(chaine, 1, 1000, fichier_a_envoyer)) > 0)
  3.     {
  4.             fwrite(chaine, 1, nb_lu, fichier_socket)   
  5.     }


Message édité par Sve@r le 17-11-2005 à 13:40:49
Reply

Marsh Posté le 17-11-2005 à 15:31:35    

Déjà merci pour vos reponses,
 

Citation :


 
    while((nb_lu=fread(chaine, 1, 1000, fichier_a_envoyer)) > 0)
    {  
            fwrite(chaine, 1, nb_lu, fichier_socket)    
    }


 
J'ai pas bien compris le:

Code :
  1. size_t nb_lu;


Si j'ai bien compris nb_lu comporte le nombre d'éléments lu, et renvois ce même nombre lors de l'écriture?  
Moi j'ai déclaré nb_lu comme un entier "int" .
 
Si non j'ai testé, et conqueror n'affiche plus les pages HTML, il cherche en boucle, alors que mon serveur à bien reçu la requete et l'a envoyé. Et sous telnet la page a bien été reçu ( sous forme HTML bien sur). Par contre l'image je peux la télécharger et puis impossible de l'ouvrir dedans j'ais toujour des caractère très bizards :s

Reply

Marsh Posté le 17-11-2005 à 16:28:17    

OP C bon ça amrche c'est super c'est de la bombe !! j'ai repris ton bout de programme, les lectures et ecritures en binaire, et en fait le pb venit de mes fermetures de fichier ^^.
   Merci a tous ;)

Reply

Marsh Posté le 18-11-2005 à 09:48:07    

marcmm13 a écrit :

J'ai pas bien compris le:

Code :
  1. size_t nb_lu;


Si j'ai bien compris nb_lu comporte le nombre d'éléments lu, et renvois ce même nombre lors de l'écriture?


Exact. Tu comptes combien d'éléments tu lis... et tu en écris autant.
Si ton fichier contient 5432 éléments (ici des octets), tu auras 5 tour de boucles où "nb_lu" = 1000 et un 6° sauf au dernier tour où "nb_lu" = 432 => ce qui te permet de n'écrire que ce que tu lis et rien d'autre
 

marcmm13 a écrit :

Moi j'ai déclaré nb_lu comme un entier "int" .


Oui, il y a eu à ce propos une grosse discussion  sur le forum (voir topic http://forum.hardware.fr/hardwaref [...] 8189-1.htm)
 
Si tu déclares "nb_lu" comme un "int", ça marche aujourd'hui parce que la valeur renvoyée par "read" rentre sur un "int" et même un int signé (elle ne peut pas dépasser 32767) mais si demain la fonction "read" est modifiée pour qu'elle puisse traiter plus d'éléments et que sa valeur ne peut rentrer que sur un "long", tu seras obligé de modifier tous tes sources où tu utilises "read" sur un "int".
 
Si tu utilises le type "size_t" (défini dans "<sys/types.h>" ) t'auras aucun problème. Aujourd'hui "size_t" est défini comme un "int", demain il sera redéfini comme il faut et toi, t'auras juste qu'à recompiler sans toucher à ton code
C'est le début de la "portabilité" !!!


---------------
Vous ne pouvez pas apporter la prospérité au pauvre en la retirant au riche.
Reply

Marsh Posté le 18-11-2005 à 10:17:24    

Sve@r a écrit :

Si tu utilises le type "size_t" (défini dans "<sys/types.h>" )


Eeek! Non! Ce header n'est pas standard. size_t est défini lorsqu'on inclue le header standard <stddef.h>, ce qui est fait automatiquement quand on inclus <stdio.h> ou <stdlib.h>.
 
Ca, c'est la suite de la portabilité !


---------------
Des infos sur la programmation et le langage C: http://www.bien-programmer.fr Pas de Wi-Fi à la maison : http://www.cpl-france.org/
Reply

Marsh Posté le 18-11-2005 à 10:17:24   

Reply

Marsh Posté le 18-11-2005 à 11:56:26    

Sve@r a écrit :

un int signé (elle ne peut pas dépasser 32767)


 
sur la plupart des plateformes les int sont sur 32 bits non ?


---------------
-( BlackGoddess )-
Reply

Marsh Posté le 18-11-2005 à 12:52:34    

blackgoddess a écrit :

sur la plupart des plateformes les int sont sur 32 bits non ?


Et ? La norme définit une taille minimale garantie.  
 
(pour simplifier)

  • char : 8-bit
  • short : 16-bit
  • int : 16-bit
  • long : 32-bit
  • long long : 64-bit [C99]


Ce qui est en plus n'est pas portable. Il existe des plateformes où les char font 16-bit. Il ne me viendrait pas à l'idée de mettre 256 dans un char pour cette raison...
 
Pour les int, c'est pareil.
 
Evidemment, il est techniquement possible d'écrire du code non portable. Il ne fonctionnera pas mieux, et constitue une bombe à retardement... Je dirait même que c'est contraire à l'éthique supposée d'un programmeur C normalement constitué...


---------------
Des infos sur la programmation et le langage C: http://www.bien-programmer.fr Pas de Wi-Fi à la maison : http://www.cpl-france.org/
Reply

Marsh Posté le 18-11-2005 à 13:54:54    

d'accord ,je n'etais pas au courant de ce minimal garanti.
est-ce ce que ces valeurs sont disponible dans un en-tête standard ?


---------------
-( BlackGoddess )-
Reply

Marsh Posté le 18-11-2005 à 15:32:47    

blackgoddess a écrit :

d'accord ,je n'etais pas au courant de ce minimal garanti.
est-ce ce que ces valeurs sont disponible dans un en-tête standard ?


Je crois que c'est dans "<limits.h>"


---------------
Vous ne pouvez pas apporter la prospérité au pauvre en la retirant au riche.
Reply

Marsh Posté le 18-11-2005 à 16:39:56    

Citation :

Evidemment, il est techniquement possible d'écrire du code non portable. Il ne fonctionnera pas mieux, et constitue une bombe à retardement... Je dirait même que c'est contraire à l'éthique supposée d'un programmeur C normalement constitué...


 
Je suis tout a fait d'accord, et encore merci pour toutes vos réponses ^^
Grace a vous j'aurai peut etre un 24/20   lol
 non serieu merci, ciao.

Reply

Marsh Posté le 18-11-2005 à 17:34:40    

blackgoddess a écrit :

d'accord ,je n'etais pas au courant de ce minimal garanti.
est-ce ce que ces valeurs sont disponible dans un en-tête standard ?


Non, ils le sont dans la norme.  


ISO/IEC 9899:1999 (E) ©ISO/IEC"
 
5.2.4.1 Translation limits
<...>
— number of bits for smallest object that is not a bit-field (byte)
CHAR_BIT 8
— minimum value for an object of type signed char
SCHAR_MIN -127 // -(27 - 1)
— maximum value for an object of type signed char
SCHAR_MAX +127 // 27 - 1
— maximum value for an object of type unsigned char
UCHAR_MAX 255 // 28 - 1
— minimum value for an object of type char
CHAR_MIN see below
— maximum value for an object of type char
CHAR_MAX see below
— maximum number of bytes in a multibyte character, for any supported locale
MB_LEN_MAX 1
— minimum value for an object of type short int
SHRT_MIN -32767 // -(215 - 1)
— maximum value for an object of type short int
SHRT_MAX +32767 // 215 - 1
— maximum value for an object of type unsigned short int
USHRT_MAX 65535 // 216 - 1
— minimum value for an object of type int
INT_MIN -32767 // -(215 - 1)
— maximum value for an object of type int
INT_MAX +32767 // 215 - 1
— maximum value for an object of type unsigned int
UINT_MAX 65535 // 216 - 1
— minimum value for an object of type long int
LONG_MIN -2147483647 // -(231 - 1)
— maximum value for an object of type long int
LONG_MAX +2147483647 // 231 - 1
— maximum value for an object of type unsigned long int
ULONG_MAX 4294967295 // 232 - 1
— minimum value for an object of type long long int
LLONG_MIN -9223372036854775807 // -(263 - 1)
— maximum value for an object of type long long int
LLONG_MAX +9223372036854775807 // 263 - 1
— maximum value for an object of type unsigned long long int
ULLONG_MAX 18446744073709551615 // 264 - 1


 
Ce qui est dans <limits.h>, ce sont les valeurs limites pour l'implémentation.

Message cité 1 fois
Message édité par Emmanuel Delahaye le 18-11-2005 à 17:51:42

---------------
Des infos sur la programmation et le langage C: http://www.bien-programmer.fr Pas de Wi-Fi à la maison : http://www.cpl-france.org/
Reply

Marsh Posté le 18-11-2005 à 18:31:07    

Emmanuel Delahaye a écrit :

Non, ils le sont dans la norme.  


ISO/IEC 9899:1999 (E) ©ISO/IEC"
 
5.2.4.1 Translation limits
<...>
— number of bits for smallest object that is not a bit-field (byte)
CHAR_BIT 8
— minimum value for an object of type signed char
SCHAR_MIN -127 // -(27 - 1)
— maximum value for an object of type signed char
SCHAR_MAX +127 // 27 - 1
— maximum value for an object of type unsigned char
UCHAR_MAX 255 // 28 - 1
— minimum value for an object of type char
CHAR_MIN see below
— maximum value for an object of type char
CHAR_MAX see below
— maximum number of bytes in a multibyte character, for any supported locale
MB_LEN_MAX 1
— minimum value for an object of type short int
SHRT_MIN -32767 // -(215 - 1)
— maximum value for an object of type short int
SHRT_MAX +32767 // 215 - 1
— maximum value for an object of type unsigned short int
USHRT_MAX 65535 // 216 - 1
— minimum value for an object of type int
INT_MIN -32767 // -(215 - 1)
— maximum value for an object of type int
INT_MAX +32767 // 215 - 1
— maximum value for an object of type unsigned int
UINT_MAX 65535 // 216 - 1
— minimum value for an object of type long int
LONG_MIN -2147483647 // -(231 - 1)
— maximum value for an object of type long int
LONG_MAX +2147483647 // 231 - 1
— maximum value for an object of type unsigned long int
ULONG_MAX 4294967295 // 232 - 1
— minimum value for an object of type long long int
LLONG_MIN -9223372036854775807 // -(263 - 1)
— maximum value for an object of type long long int
LLONG_MAX +9223372036854775807 // 263 - 1
— maximum value for an object of type unsigned long long int
ULLONG_MAX 18446744073709551615 // 264 - 1




Je présume que les "232", "263", "264" etc... signifient "2 exposant 32", "2 exposant 63" et "2 exposant 64"...  :sol:  
 

Emmanuel Delahaye a écrit :

Ce qui est dans <limits.h>, ce sont les valeurs limites pour l'implémentation.


 
Oui, je suis allé voir - Merci...  :jap:


---------------
Vous ne pouvez pas apporter la prospérité au pauvre en la retirant au riche.
Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed