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

C# Discussion :

[Sockets] Rendre la taille du buffer infinie ?


Sujet :

C#

  1. #1
    Membre du Club
    Profil pro
    Webmaster
    Inscrit en
    Mars 2006
    Messages
    88
    Détails du profil
    Informations personnelles :
    Âge : 36
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Webmaster

    Informations forums :
    Inscription : Mars 2006
    Messages : 88
    Points : 50
    Points
    50
    Par défaut [Sockets] Rendre la taille du buffer infinie ?
    Bonjour,

    J'utilise des chaines XML pour faire dialoguer mon application client-server via Sockets. Pour le protocole, il faut spécifier un buffer (byte[]) avec une taille définie (256 en général). Cependant je souhaite la rendre infinie ou qui change au fur et à mesure selon ce qui arrive.

    Le soucis est que 256 suffit amplement pour qques lignes mais si je m'envoie une image dans une chaine XML (<cmd name='picture' data='les dizaines de lignes de mon image' />), ca me l'envoie en plusieurs paquets et au moment de la transformation en XML j'obtiens une erreur car une chaine litérale (DATA) n'est pas fermée car elle est fermée qu'au 15ème paquet qui arrive ensuite. Ils arrivent séparés et ne se collent pas.

    Donc comment y remédier ?!

    Voici mon code (basique)
    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
            private void runChat()
            {
                try
                {
                    Byte[] bytes = new Byte[256]; // ici réside mon soucis car je recois en général des chaines de maxi 50charactères mais parfois pour les images c'est plus de l'ordre du millier !!
     
                    String data = String.Empty;
                    int i;
     
                    while ((i = netStream.Read(bytes, 0, bytes.Length)) != 0)
                    {
                        data = BytesToString(bytes, i);
     
                        // Traitement de la chaine XML reçue
                        DataReceived(data);
                    }
                }
                catch (Exception exe)
                {
                    // traitement de l'exception
                }
            }
    Merci à vous

  2. #2
    Expert éminent
    Avatar de StormimOn
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Mai 2005
    Messages
    2 593
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : France, Sarthe (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mai 2005
    Messages : 2 593
    Points : 7 660
    Points
    7 660
    Par défaut
    La taille du buffer n'est pas le problème, si à un moment tu dois gérer un transfert de 20Mo, ça doit aussi fonctionner sans changer la taille du buffer.

    La réception des données doit être fait en plusieurs fois, c'est tout. En gros tu remplis ton buffer de réception, tu recopies ces données dans un buffer final (pour celui là, sa taille changera au fur et à mesure de l'avancement de la réception) et tu recommences jusqu'à ce que tu ais lu toutes les données (le Read te renvoi 0 donc).

    A ce moment, tu peux traiter les données reçues.

    Pour optimiser tu peux à la rigueur ajouter dans ton protocole la taille totale des données attendues. L'idée c'est de mettre l'information dans le premier paquet envoyé pour pouvoir traiter l'information à la première lecture, comme ça tu peux prévoir la taille de ton buffer final dès le début, ça évitera de devoir refaire des allocations mémoires par la suite.

    Je ne suis pas spécialiste des sockets mais je ne pense pas avoir dit d'âneries ^^
    Pas de questions techniques par MP

  3. #3
    Expert éminent sénior
    Homme Profil pro
    Architecte technique retraité
    Inscrit en
    Juin 2008
    Messages
    21 287
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Manche (Basse Normandie)

    Informations professionnelles :
    Activité : Architecte technique retraité
    Secteur : Industrie

    Informations forums :
    Inscription : Juin 2008
    Messages : 21 287
    Points : 36 776
    Points
    36 776
    Par défaut définir vos messages.
    Si vous voulez utilisez des messages de longueur variable, il va vous falloir définir ce qu'est un message pour que le récepteur sache que la fin sera X bytes plus loin et qu'il est inutile d'essayer d'interpréter le XML avant.
    Note: Comme il faut du temps pour transferer les octets, lire 0 bytes vous indiquera que les informations ne sont pas encore arrivées.
    - W
    Architectures post-modernes.
    Python sur DVP c'est aussi des FAQs, des cours et tutoriels

Discussions similaires

  1. Socket: Tailles des buffers en émission et réception
    Par rulianf dans le forum Réseau
    Réponses: 0
    Dernier message: 17/02/2010, 16h01
  2. [Vb.NET/Sockets] Question sur la taille du buffer
    Par Aspic dans le forum VB.NET
    Réponses: 4
    Dernier message: 05/01/2010, 07h03
  3. taille du Buffer de la Socket ?
    Par HamzuS The Great dans le forum VB.NET
    Réponses: 1
    Dernier message: 06/09/2009, 15h06
  4. Réponses: 39
    Dernier message: 27/03/2007, 20h25
  5. sprintf et taille de buffer
    Par koktel_dfr dans le forum C
    Réponses: 30
    Dernier message: 24/03/2007, 01h01

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