données binaires ?

Bonjour à tous.

Je travaille avec des sockets et j'ai besoin d'echangers des ordres entre un client et un serveur. Je n'ai jamais travaillé en binaire et je ne suis pas sur de ma methode.


En gros je pense decomposer un message type de la sorte :

les 16 premiers bit pour indiquer la longueur totale du message en bit (toujours 16 bit)
les 4 bits suivant pour definir le type d'ordre à executer
(les parametres suivants dependent du type d'ordre mais par ex)
2 bit pour une direction
3 bit pour une vitesse (soit 8 vitesse possible)
etc...


Donc dans ce cas on à forcement un message de 25 bits envoyé sur le socket. Je ne sais pas si je fais pas une erreur de methode à ce niveau deja.


Ensuite la reception. Avant je travaillais avec des char et je lisais les données comme ça :

Code:

---

1 2 3

char buffer[200]; nb=recv(socket,&buffer,sizeof(buffer),0);

---

Je pense que maintenant je suis censé utiliser un tableau de boolean mais j'ai lu q'un boolean utilisait autant de mémoire q'un char soit 1 octet 8O...

Donc soit je reste sur un tableau de char sachant la j'ai par exemple 25 bit qui ne tombe pas sur un multiple d'octet. Soit je passe sur un tableau de bool.

Mais dans les deux cas, quelle est la methode la plus simple pour decomposer le message connaissant sa structure à l'avance ? Je vois bien l'utilité des >> et des masque mais je vois mal comment l'utiliser si la valeur est a cheval sur 2 octets !!

Ou alors je me plante completement.

Pouvez-vous me donner une petite explication ?

Merci à tous :)

Si t'es pas à l'aise avec les opérateurs sur les bits laisse tomber ce système.

Salut,

D'abord, il faut garder en tete que le nombre "idéal" de bits devrait toujours rester un multiple de 8 (du moins, sur les architectures de type "PC"), pour la simple et bonne raison que... c'est la taille généralement utilisée pour un type char...

Ensuite, un bit donne deux possiblités, et tu pourrais donc envisager le fait que le sens ne soit représenté que par un bit, par exemple
si 0 dans le sens serveur->client
si 1 dans le sens client->serveur
(ou l'inverse, selon ton inspiration du moment)

Enfin, il serait intéressant de prévoir:

• Quelques bits de "parité"(pour s'assurer qu'une "petite souris" n'a pas modifié un bit entre l'émetteur et le récepteur)
• Quelques bits de controle de l'ordre des instructions

Pour le premier, cela pourrait etre, par exemple, 7 bits renvoyant le modulo de tous les autres par 97 (Q: Oui, mais, pourquoi 97 :question: R: parce que c'est le dernier nombre premier avant 100)

Pour le deuxième, ce serait une valeur codée sur un nombre de bits à convenir, en "binaire réfléchi" (C'est à dire ce binaire qui permet de n'avoir qu'un seul bit qui change chaque fois que la valeur est augmentée de 1), à placer, bien évidemment, avant les bits de parité ;)

L'utilisation des bitsets (disponibles dans l'espace de nommage std) pourrait sembler etre une solution adaptée à ton problème...

Ceci dit, je rejoint l'avis de loufoque: si tu n'es pas habitué au travail en binaire, et à moins que tu ne sois tenu par certains impératifs, tu aurais peut etre plus facile à travailler sans utiliser le binaire ;)

Tu séléctionnes les bits que tu veux avec << ou >> (suivant où ils se trouvent dans l'octet) ainsi que & éventuellement pour mettre une partie qui t'interesse pas à 0 et tu combines le tout avec |.

Salut,

merci de vos réponses. Dans le protocole que j'ai exposé dans le premier post, j'ai effectivement prevus des bits de controles. Il s'agit plus de controler que les messages arrivent dans l'ordre et surtout q'un petit malin n'a pas cherché à simuler l'envois de messages entre le client et le serveur. Mais bon, de toute facon je suis en TCP donc c'est deja pas mal fiable.

J'aimerais travailler en binaire pour 2 raisons :

1) La bande passante. Avant quand j'envoyais des chaines strings au serveur, j'utilisais des carateres de séparations (soit un octet à chaque séparation). Au final pour un simple parametre pouvant etre 0 ou 1, c'etait toujours un octet complet d'envoyé. Pour ce projet, le nombre de client etant vraiment enorme, j'ai besoin de faire un max d'economie de ce côté la.

2) Dans un projet similaire, on à eu des problemes avec des clients qui "snifent" les paquets et qui parviennent aisement à comprendre/modifier le message en question. Le cryptage n'etant pas possible pour des raisons de conso CPU côté client, le fait de passer en binaire rend deja la tache plus dure. On vise pas la protection absolue de toute facon.

Donc ok, pour le protocole, je vais effectivement voir ça.

Citation:

---

D'abord, il faut garder en tete que le nombre "idéal" de bits devrait toujours rester un multiple de 8 (du moins, sur les architectures de type "PC"), pour la simple et bonne raison que... c'est la taille généralement utilisée pour un type char...

---

Cela veut-il dire que je dois toujours completer avec des bits 0 mon dernier octet par exemple ? Je precise que le serveur est unique et qu'il tournera sur une plateforme linux. Dans ce cas, les bits indiquant la longueur totale du message indiquera le nombre d'octets et non de bits. J'économise qq bits aussi la dessus dans ce cas :)

Je vais donc insister sur le binaire, je pense connaitre juste ce qu'il faut sur la gestion bas niveau pour pouvoir travailler dessus. Sinon j'apprendrai :)

Le client me permet de coder dans un langage qui sera ensuite interprété. L'avantage c'est que ce langage integre directement des fonctions genre readInt() ou getBytes(nb_bits) le tout sur des tableaux de bytes (et non pas de bits) en gros comme si c'etait un tableau de char quoi.

J'ai deja pas mal bossé avec les masques et les >> sur des bits. Je me demmandais juste si y avait une méthode connus assez simple à mettre en oeuvre pour decomposer mon message. Pour ma curiosité perso j'aimerais ne pas avoir à utiliser la STL.

Donc au final, je me retrouve avec un tableau de char et je dois lire à coup de X bits à chaque fois pour en sortir un int finalement. Bon au pire je pense pouvoir ecrire un classe qui gere ce genre de chose mais des conseils seraient les bienvenues :)

La question que je me pose c'est, est-ce que l'economie de bande passante en codant à coup de bit justifie une surconso de CPU pour decomposer mes messages. Evidement le tout serait plus simple si je travaillais à coup d'octet. En même temps les messages ne sont pas long, 50 octets en moyenne. Mais ils sont nombreux !!

Citation:

---

Envoyé par loufoque

Tu séléctionnes les bits que tu veux avec << ou >> (suivant où ils se trouvent dans l'octet) ainsi que & éventuellement pour mettre une partie qui t'interesse pas à 0 et tu combines le tout avec |.

---

Oui c'est bien ce que je pensais, ce qui rend les chose plus complexes c'est que finalement un parametre de 5 bits peut etre à cheval sur 2 octets !! je vais donc boucler quelque part au cas ou je demmande des params de 32 bits par exemple. Donc effectivement je vais faire quelques | pour assembler le tout !

Citation:

---

Envoyé par seal3

(snip)
Cela veut-il dire que je dois toujours completer avec des bits 0 mon dernier octet ? On y gagne qq part ? Je precise que le serveur est unique et qu'il tournera sur une plateforme linux. Dans ce cas, les bits indiquant la longueur totale du message indiquera le nombre d'octets et non de bits. J'économise qq bits aussi la dessus dans ce cas :)
(snip)

---

Disons que L'utilisation de multiples de 8 bits sera surtout plus de nature à te permettre d'utiliser l'architecture interne de ton processeur...

Il faut bien comprendre que, finalement, quasi toute l'architecture d'un processeur va travailler avec des multiples de 8 bits (du moins, sur les descendants de la famille X86)...

Il faut bien comprendre, aussi, qu'il faudrait vraiment un nombre incroyable de clients connectés au meme moment sur le serveur (et, surtout, qui essayent en meme temps de communiquer avec) pour que 7 malheureux bits envoyés en plus (au maximum) fassent saturer la bande passante... Surtout quand on voit les vitesses de connexion actuellement atteinte (si on en était encore à l'époque pionière des transmissions à 26 Kb/s, j'aurais peut etre réagit autrement... mais elle est tres loin, déjà ;) )

Il faut bien comprendre, enfin, que ce que tu "gagne" en bande passante en "évitant" d'envoyer 7 malheureux bits, tu va de toutes manière le "perdre" au niveau du processeur, parce que ca n'entre pas correctement dans ses "échelles de valeurs"...

Par contre, plutot que de completer le dernier octet avec des 0, pourquoi ne pas plutot envisager l'inverse: ne pas toucher aux bits inutilisés du premier :question:

Pour l'instant, tu te base sur 25 bits utilisés, ce qui fait 4 octets (pour que le 25eme bit puisse entrer), et tu envisage de travailler sous la forme de

Code:

---

1 2 3

Bits utilises |Bits inutilises 00000000 00000000 00000000 0|0000000

---

Mais, n'aurais tu pas plus facile de travailler sous la forme de

Code:

---

1 2 3

inutili|bits utilises 0000000|0 00000000 00000000 00000000

---

Citation:

---

Envoyé par seal3

Oui c'est bien ce que je pensais, ce qui rend les chose plus complexes c'est que finalement un parametre de 5 bits peut etre à cheval sur 2 octets !! je vais donc boucler quelque part au cas ou je demmande des params de 32 bits par exemple. Donc effectivement je vais faire quelques | pour assembler le tout !

---

Pourquoi ne pas prendre un type "classique" qui permette de disposer d'au minimum 25 bits :question:

Envoie simplement un int ou un unsigned int... tu *devrais* (à moins que tu n'utilise un tres vieux compilo) pouvoir disposer de 32 bits d'un seul coup, et dans une seule variable...

Tu utilises les bits de 0 à 24 et tu laisses les bits de poids le plus fort tranquils... Et le tour est joué...

Tu pourra meme faire une vérification supplémentaire sur la valeur renvoyée qui devra etre, en tout état de cause, inférieure ou égale à 0x1FFFFFF (33 554 431 en décimal)... (sinon, c'est qu'une souris est passée par là ;) )

Et, honnetement, ce n'est pas *vraiment* le fait d'envoyer 32 bits (+/-, dépendemment de l'implémentation des int) qui te fera perdre énormément de bande passante (un peu plus que 4 char, soit, mais, pas suffisemment pour que cela influe réellement)...

C'est sans compter sur le fait que, idéalement, le flux envoyé sur le réseau doit etre assez long pour atteindre tous les postes avant que l'émission ne cesse (dépendemment de l'implémentation du réseau)... et que, selon l'implémentation du réseau, il serait sans doute meme utile d'envisager un flux de taille suppérieure...

oui tu as raison, 7 bits ce n'est pas ce qui va plomber mon serveur :) il suffit de les laisser passer sans y toucher. De toute facon je viens de me rendre compte que côté client je ne peux envoyer que des bytes (octets) et non pas bit par bit !!

En fait la ou je pense vraiment y gagner c'est quand j'ai besoin d'envoyer par ex 20 bool à la suite. Dans ce cas je n'ai besoin que de 20 bits et non pas 20 octets !! C'est surtout pour cela que je veux bosser en binaire :)

Par contre dans le protocol, je vais avoir besoin à un moment donné de faire passer un string dont la taille m'est inconnue. Je me suis dit qu'il me suffisait de mettre un octet 0 pour marquer la fin de ma chaine. Même si ces 8 bits à 0sont à cheval sur 2 octets.

Du coup avec cette chaine j'ai besoin d'informer le serveur sur le nombre d'octets qu'il est cencé lire afin de distinguer le message en cours du suivant si jamais il sont colés l'un au bout de l'autre. J'ai donc pensé à mettre cette information sur 2 octets ce qui est largement suffisent puisque cela correspond à un message de plus de 65Ko, ce qui n'arrivera jamais normalement.

Mais du coup je suis obligé de placer ces 2 octets en debut de message puisque je vais faire en sorte que le serveur lise forcement les 2 premiers octets afin de considerer les X octets suivants comme faisant partit du même message. Donc je suis obligé d'utiliser les bits de poids fort :(.

En tout cas merci à toi de prendre le temps de m'expliquer. Vue que je m'y suis jamais penché dessus, ça prend forme dans ma tête petit à petit :)

Citation:

---

Par contre dans le protocol, je vais avoir besoin à un moment donné de faire passer un string dont la taille m'est inconnue. Je me suis dit qu'il me suffisait de mettre un octet 0 pour marquer la fin de ma chaine.

---

Tu ferais mieux d'indiquer la longueur au préalable.