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 :

Send() et Recv() non coordonnées


Sujet :

Réseau C

  1. #21
    Inactif  
    Avatar de Mac LAK
    Profil pro
    Inscrit en
    Octobre 2004
    Messages
    3 893
    Détails du profil
    Informations personnelles :
    Âge : 49
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations forums :
    Inscription : Octobre 2004
    Messages : 3 893
    Points : 4 846
    Points
    4 846
    Par défaut
    Citation Envoyé par theawe Voir le message
    J'en aurais même presque honte .
    Bah, ça passe vite, on a tous été débutants un jour.

    Citation Envoyé par theawe Voir le message
    1) Si jamais je garde la méthode des chaînes de caractères, je ne vois pas comment préciser la taille de la donnée dans l'entête, pour pouvoir ne récupérer que cette taille côté client.
    Avec des chaînes, il faut avoir un "code" de taille fixe (quelques caractères, donc), pour savoir quoi faire.
    Ensuite, il faut envoyer la taille dans un format fixe : l'idéal pour ça, c'est encore d'utiliser de l'hexadécimal 32 bits, donc 8 caractères. C'est en taille fixe, mais c'est plus lourd bien sûr.

    Citation Envoyé par theawe Voir le message
    En me basant sur ton exemple :
    ORDRE(16) : Transfert de fichier, envoi du nom.
    NOM DE FICHIER : NomDuFichier.txt
    Je ne vois pas comment le client récupère la valeur 16.
    Perso, je ferais ainsi (je n'ai pas mis le code "inutile", juste l'essentiel et "à la louche") :
    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
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    // Codes d'opérations.
    typedef enum {
      opFilename = 0,   // Prochaine donnée : nom du fichier.
      opFilesize,       // Prochaine donnée : taille du fichier.
      opFiledata,       // Prochaine donnée : contenu du fichier.
      opEnd             // Fin du protocole, on arrête le client. Pas de données à la suite.
    } COpcodes ;
     
    // Entête du protocole.
    typedef struct {
      int Opcode ;      // Code de l'opération.
      int DataSize ;    // Taille des données qui vont suivre.
    } CHeader ;
     
    int main ( void ) {
     
    ....
     
      // Code d'émission.
      CHeader hdr ;
      char* filename = "........" ;
      unsigned long int filesize = .......... ;
      char buffer[BUFSIZ] ;
      ssize_t rd ;
     
     
      hdr.Opcode = opFilename ;
      hdr.DataSize = strlen(filename);
      send(sock,&hdr,sizeof(hdr),0);
      send(sock,filename,strlen(filename),0);
      hdr.Opcode = opFileSize ;
      hdr.DataSize = sizeof(filesize);
      send(sock,&hdr,sizeof(hdr),0);
      send(sock,&filesize,strlen(filesize),0);
      hdr.Opcode = opFiledata ;
      hdr.DataSize = filesize ;
      send(sock,&hdr,sizeof(hdr),0);
      // Boucle d'envoi du fichier, "filesize" octets.
      for (unsigned long int k = filesize ; k >0 ; ) {
        // On lit ce qui va bien : soit la taille maximale du buffer, soit ce qu'il reste à lire.
        rd = read(file,buffer,min(BUFSIZ,k)) ;
        // Si l'on a lu des données, on les envoie.
        if (rd>0) {
          send(sock,buffer,rd);
          // Et on met à jour la taille restante.
          k -=rd ;
        }
      } 
     
    ....
     
      return 0 ;
    }
    Citation Envoyé par theawe Voir le message
    2) Est-ce possible de déclarer 1 structure pour chaque information ?
    Inutile, voire dangereux : on n'en connait pas la taille. Passer par un code numérique (ou texte, mais de taille fixe) est préférable.

    Citation Envoyé par theawe Voir le message
    Je risque d'avoir des problèmes au niveau de la taille de enteteNomFichier si le nom varie je suppose...
    C'est exactement ça.

    Citation Envoyé par theawe Voir le message
    3) Qu'entends-tu par "envois de façon binaire" ? envoi de types différents de tous ceux relatifs aux chaînes de caractères ?
    Ci-dessus, ce sont des envois binaires que j'ai fait : j'ai pris l'adresse d'une structure, et je l'ai expédiée sur la socket. On parle d'envois texte quand on se limite (volontairement) aux seuls caractères, affichables le plus souvent, mais une socket est par nature binaire... Et au moins, ça évite d'avoir des soucis avec les CR/LF, LF, CR....
    Mac LAK.
    ___________________________________________________
    Ne prenez pas la vie trop au sérieux, de toutes façons, vous n'en sortirez pas vivant.

    Sources et composants Delphi sur mon site, L'antre du Lak.
    Pas de question technique par MP : posez-la dans un nouveau sujet, sur le forum adéquat.

    Rejoignez-nous sur : Serveur de fichiers [NAS] Le Tableau de bord projets Le groupe de travail ICMO

  2. #22
    Membre du Club
    Profil pro
    Inscrit en
    Janvier 2009
    Messages
    96
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Janvier 2009
    Messages : 96
    Points : 44
    Points
    44
    Par défaut
    J'ai bien compris ce que tu as fais et t'en remercie. Il reste cependant une chose à voir.
    Prenons cet extrait du code :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
     
      hdr.Opcode = opFilename ;
      hdr.DataSize = strlen(filename);
      send(sock,&hdr,sizeof(hdr),0);
      send(sock,filename,strlen(filename),0);
    Comment je peux récupérer la taille de la structure CHeader au niveau du client, pour savoir à quel moment je dois arrêter de lire la structure ?

  3. #23
    Inactif  
    Avatar de Mac LAK
    Profil pro
    Inscrit en
    Octobre 2004
    Messages
    3 893
    Détails du profil
    Informations personnelles :
    Âge : 49
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations forums :
    Inscription : Octobre 2004
    Messages : 3 893
    Points : 4 846
    Points
    4 846
    Par défaut
    Citation Envoyé par theawe Voir le message
    Comment je peux récupérer la taille de la structure CHeader au niveau du client, pour savoir à quel moment je dois arrêter de lire la structure ?
    Un protocole de communication doit être connu des DEUX côtés de la barrière... En C, ça veut en général dire que la partie client et la partie serveur partagent au minimum un fichier .H en commun, parfois beaucoup plus.

    Cet entête commun définit notamment les structures de communication utilisées...
    Mac LAK.
    ___________________________________________________
    Ne prenez pas la vie trop au sérieux, de toutes façons, vous n'en sortirez pas vivant.

    Sources et composants Delphi sur mon site, L'antre du Lak.
    Pas de question technique par MP : posez-la dans un nouveau sujet, sur le forum adéquat.

    Rejoignez-nous sur : Serveur de fichiers [NAS] Le Tableau de bord projets Le groupe de travail ICMO

  4. #24
    Membre du Club
    Profil pro
    Inscrit en
    Janvier 2009
    Messages
    96
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Janvier 2009
    Messages : 96
    Points : 44
    Points
    44
    Par défaut
    Citation Envoyé par Mac LAK Voir le message
    Un protocole de communication doit être connu des DEUX côtés de la barrière... En C, ça veut en général dire que la partie client et la partie serveur partagent au minimum un fichier .H en commun, parfois beaucoup plus.

    Cet entête commun définit notamment les structures de communication utilisées...
    Je ne vais pas développer un fichier .h pour le moment. Pour m'en passer, je peux déclarer la structure dans le fichier .h de la classe que je développe actuellement (côté client) ?
    En fait au moment du recv(), dois-je déterminer la taille d'un header de cette façon là : sizeof(hdr), si j'ai déclaré une structure de type CHeader ?

  5. #25
    Inactif  
    Avatar de Mac LAK
    Profil pro
    Inscrit en
    Octobre 2004
    Messages
    3 893
    Détails du profil
    Informations personnelles :
    Âge : 49
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations forums :
    Inscription : Octobre 2004
    Messages : 3 893
    Points : 4 846
    Points
    4 846
    Par défaut
    Citation Envoyé par theawe Voir le message
    Je ne vais pas développer un fichier .h pour le moment. Pour m'en passer, je peux déclarer la structure dans le fichier .h de la classe que je développe actuellement (côté client) ?
    Alors tu vas au casse-gueule.

    Un protocole de communication, quel qu'il soit, doit être implémenté exactement de la même manière des deux côtés. Le plus simple, c'est de faire un bout de code commun aux deux éléments de la communication (émetteur / récepteur), mais parfois on le fait aussi sur spécifications (ex : RFC des protocoles Internet).

    Dans tous les cas, si les deux processus n'utilisent pas exactement les mêmes données, au bit près, c'est mort.

    Citation Envoyé par theawe Voir le message
    En fait au moment du recv(), dois-je déterminer la taille d'un header de cette façon là : sizeof(hdr), si j'ai déclaré une structure de type CHeader ?
    Oui, mais encore faudrait-il que tu l'aie bien déclaré de la même manière... D'où le .H commun...
    Mac LAK.
    ___________________________________________________
    Ne prenez pas la vie trop au sérieux, de toutes façons, vous n'en sortirez pas vivant.

    Sources et composants Delphi sur mon site, L'antre du Lak.
    Pas de question technique par MP : posez-la dans un nouveau sujet, sur le forum adéquat.

    Rejoignez-nous sur : Serveur de fichiers [NAS] Le Tableau de bord projets Le groupe de travail ICMO

  6. #26
    Membre du Club
    Profil pro
    Inscrit en
    Janvier 2009
    Messages
    96
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Janvier 2009
    Messages : 96
    Points : 44
    Points
    44
    Par défaut
    Là, j'ai du mal à saisir, et c'est purement par défaut de connaissances au niveau du langage.

    En reprenant ton exemple de structure : La taille en octet d'une structure CHeader, varie t-elle en fonction de la valeur que prennent les variables qui la composent, ou aura t-elle toujours la même taille, quelques soient ces valeurs ?
    Je pensais, mais peut-être à tord, qu'une structure englobant deux variables d'un type connu, a une taille basée en partie (ou en totalité ?) sur le type des deux variables qui la composent ?

    Exemple :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
     
    CHeader hdr;
    hdr.OpCode = opFileName;
    hdr.dataSize = 12;
    int iSize_hdr = sizeof(hdr);
     
    CHeader hdr1;
    hdr1.OpCode = opFileSize;
    hdr1.dataSize = 12345;
    int iSize_hdr1 = sizeof(hdr1);
    Est-ce que dans le cas ci-dessus, iSize_hdr = iSize_hdr1 ?

    Quand je disais me passer d'un fichier .h commun, je voulais simplement dire que j'allais déclarer côté client et serveur, la structure et l'enum.

    Qu'est-ce qui ne colle pas ?

    Lorsque tu dis que " si les deux processus n'utilisent pas exactement les mêmes données, au bit près, c'est mort ", dois-je comprendre que tu parles effectivement des données contenues dans les variables ou bien des variables elles-mêmes ?

  7. #27
    Inactif  
    Avatar de Mac LAK
    Profil pro
    Inscrit en
    Octobre 2004
    Messages
    3 893
    Détails du profil
    Informations personnelles :
    Âge : 49
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations forums :
    Inscription : Octobre 2004
    Messages : 3 893
    Points : 4 846
    Points
    4 846
    Par défaut
    Citation Envoyé par theawe Voir le message
    En reprenant ton exemple de structure : La taille en octet d'une structure CHeader, varie t-elle en fonction de la valeur que prennent les variables qui la composent, ou aura t-elle toujours la même taille, quelques soient ces valeurs ?
    La taille est toujours fixe sur un système donné (en fonction de la taille des champs et de l'alignement). Toutefois, quand la structure contient des pointeurs, la taille des données "tenues" par la structure varie, même si la taille de la structure elle-même est constante.

    Citation Envoyé par theawe Voir le message
    Est-ce que dans le cas ci-dessus, iSize_hdr = iSize_hdr1 ?
    Oui. Et ceci quelles que soient les données contenues dans les structures en question.

    Citation Envoyé par theawe Voir le message
    Quand je disais me passer d'un fichier .h commun, je voulais simplement dire que j'allais déclarer côté client et serveur, la structure et l'enum.
    Ce qui est déjà en soi une mauvaise idée : toute modification devra être faite deux fois... Classiquement, on oublie souvent de modifier le deuxième.

    Citation Envoyé par theawe Voir le message
    Lorsque tu dis que " si les deux processus n'utilisent pas exactement les mêmes données, au bit près, c'est mort ", dois-je comprendre que tu parles effectivement des données contenues dans les variables ou bien des variables elles-mêmes ?
    Les deux. Ce qu'envoie le serveur doit être compris par le client, et réciproquement. N'oublie pas que les deux systèmes ne "voient" pas les variables de l'autre, elles passent par le réseau et doivent donc sortir de la machine suivant un encodage très précis, afin que l'autre machine puisse la décoder et obtenir quelque chose de "lisible".

    Là, encore, tu es dans un cas simple (pas de contraintes d'alignement, d'endianess, etc.), mais fais-moi confiance : la déclaration d'une structure portable destinée à un réseau peut assez vite devenir infecte, pour justement qu'elle puisse être "comprise" par n'importe qui utilisant ledit réseau.

    Toi, tu travailles sur deux machines identiques, tu as donc cette simplification non négligeable. Mais si tu veux éviter les ennuis, prends l'habitude de déclarer systématiquement les structures de communication (et, si elles existent, les fonctions "helpers" de ces structures, par exemple copie, allocation, libération, vidage, etc.) dans un module commun, et non pas de re-déclarer les structures dans un autre programme.
    Mac LAK.
    ___________________________________________________
    Ne prenez pas la vie trop au sérieux, de toutes façons, vous n'en sortirez pas vivant.

    Sources et composants Delphi sur mon site, L'antre du Lak.
    Pas de question technique par MP : posez-la dans un nouveau sujet, sur le forum adéquat.

    Rejoignez-nous sur : Serveur de fichiers [NAS] Le Tableau de bord projets Le groupe de travail ICMO

  8. #28
    Membre du Club
    Profil pro
    Inscrit en
    Janvier 2009
    Messages
    96
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Janvier 2009
    Messages : 96
    Points : 44
    Points
    44
    Par défaut
    Ok, bien compris. Là, dans mon cas, je travaille simplement sur une ébauche. Je tente de mettre au point des fonctionnalités et ce, simplement pour prendre de l'avance par rapport à un futur projet. Je ne voyais à terme aucune déclaration de ma structure dans autre chose qu'un entête commun aux deux applications.

    Merci pour tout. Je laisse le topic non résolu pour le moment, au cas où, mais... normalement, le statut du fil devrait changer très bientôt.

  9. #29
    Inactif  
    Avatar de Mac LAK
    Profil pro
    Inscrit en
    Octobre 2004
    Messages
    3 893
    Détails du profil
    Informations personnelles :
    Âge : 49
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations forums :
    Inscription : Octobre 2004
    Messages : 3 893
    Points : 4 846
    Points
    4 846
    Par défaut
    Citation Envoyé par theawe Voir le message
    Je ne voyais à terme aucune déclaration de ma structure dans autre chose qu'un entête commun aux deux applications.
    Tu débutes dans les réseaux, mais, stp, prends de bonnes habitudes dès le départ... L'entête/module commun, ça doit devenir un réflexe ! Surtout en phase d'essais, où on les modifie sans arrêt !
    Mac LAK.
    ___________________________________________________
    Ne prenez pas la vie trop au sérieux, de toutes façons, vous n'en sortirez pas vivant.

    Sources et composants Delphi sur mon site, L'antre du Lak.
    Pas de question technique par MP : posez-la dans un nouveau sujet, sur le forum adéquat.

    Rejoignez-nous sur : Serveur de fichiers [NAS] Le Tableau de bord projets Le groupe de travail ICMO

  10. #30
    Membre du Club
    Profil pro
    Inscrit en
    Janvier 2009
    Messages
    96
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Janvier 2009
    Messages : 96
    Points : 44
    Points
    44
    Par défaut
    Je sais bien que tu as raison .
    Tu vois, je n'ai pas tardé à revenir finalement... voilà où j'en suis : j'ai totalement développé les fonctionnalités de chaque côté et je rencontre une nouvelle difficulté. Je reçois tous les entêtes correctement, sauf celui concernant opFileData (pour reprendre ton exemple).

    Je réalise mon send() de la manière suivante :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
     
    hdr.Opcode = opFileData;
    hdr.dataSize = fileSize;
    send(socket, (const char*)&hdr, sizeof(hdr), 0);
    L'envoi est bon, j'ai vérifié les valeurs à l'aide d'un point d'arrêt. C'est la réception qui cloche, puisqu'au lieu de recevoir Opcode = 3 et dataSize = 13630, je reçois Opcode = 1040187392 et dataSize = 114085741. Ce que je ne comprends pas, c'est que pour ces données là, rien ne va, alors que pour les réceptions précédentes les données passaient bien.

    Une idée peut-être ?

  11. #31
    Inactif  
    Avatar de Mac LAK
    Profil pro
    Inscrit en
    Octobre 2004
    Messages
    3 893
    Détails du profil
    Informations personnelles :
    Âge : 49
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations forums :
    Inscription : Octobre 2004
    Messages : 3 893
    Points : 4 846
    Points
    4 846
    Par défaut
    Citation Envoyé par theawe Voir le message
    Ce que je ne comprends pas, c'est que pour ces données là, rien ne va, alors que pour les réceptions précédentes les données passaient bien.
    Tu n'as pas oublié de lire des données précédentes ?
    Es-tu certain que tu n'as pas écrit des données pourries dans l'entête (avec un cast implicite foireux, par exemple) ?
    Mac LAK.
    ___________________________________________________
    Ne prenez pas la vie trop au sérieux, de toutes façons, vous n'en sortirez pas vivant.

    Sources et composants Delphi sur mon site, L'antre du Lak.
    Pas de question technique par MP : posez-la dans un nouveau sujet, sur le forum adéquat.

    Rejoignez-nous sur : Serveur de fichiers [NAS] Le Tableau de bord projets Le groupe de travail ICMO

  12. #32
    Membre du Club
    Profil pro
    Inscrit en
    Janvier 2009
    Messages
    96
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Janvier 2009
    Messages : 96
    Points : 44
    Points
    44
    Par défaut
    Citation Envoyé par Mac LAK Voir le message
    Tu n'as pas oublié de lire des données précédentes ?
    Non. Toutes les données ont été lues.

    Citation Envoyé par Mac LAK Voir le message
    Es-tu certain que tu n'as pas écrit des données pourries dans l'entête (avec un cast implicite foireux, par exemple) ?
    Certain. Je n'ai pas eu besoin de faire un seul cast. J'ai par ailleurs vérifié les données, dans la structure envoyée par send().

  13. #33
    Inactif  
    Avatar de Mac LAK
    Profil pro
    Inscrit en
    Octobre 2004
    Messages
    3 893
    Détails du profil
    Informations personnelles :
    Âge : 49
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations forums :
    Inscription : Octobre 2004
    Messages : 3 893
    Points : 4 846
    Points
    4 846
    Par défaut
    Alors fais une trace : que ce soit au niveau de l'émetteur (juste avant le send) ou au niveau du récepteur (juste après le recv), affiche tout ce que tu as reçu.
    Affiche aussi (et surtout !!) le retour des fonctions send et recv, et mets ici les traces en question.
    Mac LAK.
    ___________________________________________________
    Ne prenez pas la vie trop au sérieux, de toutes façons, vous n'en sortirez pas vivant.

    Sources et composants Delphi sur mon site, L'antre du Lak.
    Pas de question technique par MP : posez-la dans un nouveau sujet, sur le forum adéquat.

    Rejoignez-nous sur : Serveur de fichiers [NAS] Le Tableau de bord projets Le groupe de travail ICMO

  14. #34
    Membre du Club
    Profil pro
    Inscrit en
    Janvier 2009
    Messages
    96
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Janvier 2009
    Messages : 96
    Points : 44
    Points
    44
    Par défaut
    Bonjour,

    Je n'ai pas utilisé les traces, parce que pas à l'aise avec cet outil. Je leur ai préféré l'affichage dans un fichier.
    La structure CHeader a une taille de 8 octets.

    Niveau récepteur, tout ce qui est reçu avant le recv() de la structure pour le contenu du fichier est correct : Les données dans la structure précédente correspondent à ce qui a été envoyé. OpCode = 2 = opFileType (pour le type du fichier). dataSize = 3 (pour "bin" ou "txt").

    Niveau émetteur, avant l'appel du send() de la structure relative au contenu du fichier, tout est correct. Les données dans la structure sont bien OpCode = 2 = opFileType et dataSize = 3.

    Le remplissage de la structure en rapport avec le contenu du fichier est correct côté émetteur : J'envoie bien OpCode = opFileData = 3 et dataSize = taille du fichier.
    Le send() envoie alors 8 octets. J'envoie donc bien ma structure avec les bonnes données.

    Côté récepteur, ça se corse au niveau de la réception : Je reçois le contenant mais pas le contenu. Le retour de recv() est de 8 octets, mais les données sont : OpCode = 1040187392 et dataSize = 1140850741.

    Est-ce qu'un trace pourrait donner des résultats différents ?

  15. #35
    Inactif  
    Avatar de Mac LAK
    Profil pro
    Inscrit en
    Octobre 2004
    Messages
    3 893
    Détails du profil
    Informations personnelles :
    Âge : 49
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations forums :
    Inscription : Octobre 2004
    Messages : 3 893
    Points : 4 846
    Points
    4 846
    Par défaut
    Citation Envoyé par theawe Voir le message
    Je n'ai pas utilisé les traces, parce que pas à l'aise avec cet outil. Je leur ai préféré l'affichage dans un fichier.
    ... Heu, c'est ça, des traces, justement, bien que l'utilisation de la console soit souvent plus pratique.

    Citation Envoyé par theawe Voir le message
    Niveau émetteur, avant l'appel du send() de la structure relative au contenu du fichier, tout est correct. Les données dans la structure sont bien OpCode = 2 = opFileType et dataSize = 3.
    Et la lecture des trois caractères, justement ? Il n'y a pas un octet nul qui se balade ? Ou tout simplement un oubli de lire ces trois caractères ?

    Citation Envoyé par theawe Voir le message
    Est-ce qu'un trace pourrait donner des résultats différents ?
    C'est pour ça que je te demandais de mettre tes traces ici... Voir si tu n'as pas oublié quelque chose, justement.
    Trace serveur, trace client, et ce que tu crois avoir envoyé (d'un point de vue logique).
    Mac LAK.
    ___________________________________________________
    Ne prenez pas la vie trop au sérieux, de toutes façons, vous n'en sortirez pas vivant.

    Sources et composants Delphi sur mon site, L'antre du Lak.
    Pas de question technique par MP : posez-la dans un nouveau sujet, sur le forum adéquat.

    Rejoignez-nous sur : Serveur de fichiers [NAS] Le Tableau de bord projets Le groupe de travail ICMO

  16. #36
    Membre du Club
    Profil pro
    Inscrit en
    Janvier 2009
    Messages
    96
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Janvier 2009
    Messages : 96
    Points : 44
    Points
    44
    Par défaut
    Je te répondrai plus en détail dès que je pourrai à nouveau lancer mes deux applications, parce que là, un serveur semble rencontrer quelques soucis et je n'ai pas accès à l'ensemble des objets ciblés par mes sources, mais je viens de constater une anomalie dans le code, pile à l'endroit où t'as mené ton intuition : j'ai oublié d'utiliser les données dans la structure reçue lors de l'appel à recv() postérieur. Cependant il me semble que j'avais traité ceci au début mais je l'ai surement modifié en nettoyant un peu le code. C'est sûr que ça ne risque pas d'être fonctionnel comme ça. Je te tiens au courant dès que je le pourrai techniquement parlant.

  17. #37
    Inactif  
    Avatar de Mac LAK
    Profil pro
    Inscrit en
    Octobre 2004
    Messages
    3 893
    Détails du profil
    Informations personnelles :
    Âge : 49
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations forums :
    Inscription : Octobre 2004
    Messages : 3 893
    Points : 4 846
    Points
    4 846
    Par défaut
    Cas classique. Les traces, y'a que ça de vrai...

    Plus sérieusement, avec de l'habitude, tu peux avoir le même résultat sans traces "réelles", en analysant ton propre source. Mais tant que tu n'as pas cette habitude, prends celle de faire des traces. L'utilisation de celles "par défaut" de Visual est pratique, mais non obligatoire, il y a pas mal de systèmes de log plus ou moins complexes (et pratiques) disponibles sur le site, cherche dans les sources C notamment.
    Mac LAK.
    ___________________________________________________
    Ne prenez pas la vie trop au sérieux, de toutes façons, vous n'en sortirez pas vivant.

    Sources et composants Delphi sur mon site, L'antre du Lak.
    Pas de question technique par MP : posez-la dans un nouveau sujet, sur le forum adéquat.

    Rejoignez-nous sur : Serveur de fichiers [NAS] Le Tableau de bord projets Le groupe de travail ICMO

  18. #38
    Membre du Club
    Profil pro
    Inscrit en
    Janvier 2009
    Messages
    96
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Janvier 2009
    Messages : 96
    Points : 44
    Points
    44
    Par défaut
    Bon... Eh bien on dirait que tout fonctionne à présent.

+ Répondre à la discussion
Cette discussion est résolue.
Page 2 sur 2 PremièrePremière 12

Discussions similaires

  1. Sur un socket : send et recv ou read et write ?
    Par Médinoc dans le forum Réseau
    Réponses: 35
    Dernier message: 05/11/2009, 15h51
  2. [socket] Pb send() et recv()
    Par Tymk dans le forum C++
    Réponses: 6
    Dernier message: 03/06/2008, 18h44
  3. pb avec send et recv de mpi
    Par fatjoe dans le forum C++
    Réponses: 0
    Dernier message: 24/02/2008, 21h54
  4. socket send et recv
    Par sebatlante dans le forum Réseau
    Réponses: 24
    Dernier message: 29/08/2007, 01h34
  5. Question sur les fonctions "send()" et "recv(
    Par damien99 dans le forum MFC
    Réponses: 6
    Dernier message: 10/02/2006, 20h47

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