Version imprimable
Bonjour,
Dans un développement d'un proxy (qui n'est pas de moi), une personne utilise un ByteBuffer pour transférer les données entre les différentes sockets.
Je souhaiterais connaitre la taille des données transférées entre les sockets. Cependant je n'arrive pas à comprendre comment je peux récupérer cette taille en octets.
Quelqu'un aurait-il une idée ?
Merci d'avance pour votre aide.
As-tu cherché dans la Javadoc ?
Bonjour,
Je ne comprends pas trop ton problème, si tu connais la personne qui utilise le byteBuffer, ou que tu a vu le code, pourquoi ne pas lui demander de te donner la capacity de celui-ci (ou de lire le code) ?
Sinon, si tu n'a accès qu'à l'autre coté du socket, je ne vois pas de moyen dans la mesure où un socket n'a aucune connaissance de la classe ByteBuffer, ni même du langage java, à moins que le protocile d'échange prévoie un octet ou un marqueur de fin de bloc qui soit placé tous les X octets, en supposant que ce nombre soit celui de la capacity du buffer, ce qui n'est pas sûr.
Cordialement
Cordialement
On s'en tape de la capacity, ce n'est qu'un buffer. Il vaut mieux jeter un œil du côté des appels à ReadableByteChannel.read() ou WritableByteChannel.write(), et compter le nombre d'octets vraiment lus ou écrits.
En effet, mea culpa, j'ai mal formulé ma question. J'étais plus dans le doute de savoir l'information la plus fiable pour avoir le nombre de bytes échangés.
J'ai procédé comme suit :
Le code actuel appelle une fonction transfer qui est appelé à chaque fois que mon buffer est plein. Dans cette fonction, je récupère les bytes lus dans la socket :
int numRead = socket.read(MyByteBuffer);
J'utilise cette valeur que j'incrémente pour connaitre le nombre de bytes total récupérés dans ma socket.
J'ai quand même des valeurs assez étranges comme une page web dont le Header indique Content-length : 880 et j'ai 45321 bytes récupérés. Cela est peut être du à un mauvais codage, je vais revérifier mon code.
Merci pour votre aide.
Bonjour,
Petit aparté pour thelvin, on ne dit pas "on s'en tape de..' mais "je pense que la question posée ne concerne pas la capacity ..." C'est plus poli et ça fait preuve d'un peu plus de respect vis à vis des gens (en l’occurrence, moi) qui tentent de rendre service et qui, comme tout un chacun, peuvent comprendre de travers une question.
Ensuite, pour FinalSpirit, j'ai effectivement été induit en erreur par le titre de ton message. Par contre, je me demande quelle est la classe de cet objet que tu nommes "socket" et qui possède une méthode read(ByteBuffer) ?
Est-ce une classe d'encapsulation de la classe Socket faite par toi ?
Si oui, peut-être le code nous aiderait à comprendre la raison de ces tailles apparemment erronées
Cordialement
Oui en effet, je n'ai pas précisé, c'est un SocketChannel d'où la méthode read. Les java.nio.channels.Selector et java.nio.channels.SocketChannel sont utilisé pour gérer les différentes demandes des applications.
Bonjour,
Dans ce cas, ça doit être vrai, tu peut le vérifier en conservant la valeur de MyByteBuffer.remaining() et en la comparant avec ce même appel au retour du read, ça devrait être égal au retour de la fonction read.
Tu as parlé de pages web, il n'y aurait pas des images ou autres gros objets genre CDATA qui transitent sur cd même canal ?
Cordialement
Il y a en effet des images et autres gros objets qui peuvent transiter. Pour le moment je n'ai pas vu de soucis. Le proxy est assez simple :
- Une socket est ouverte lors de l'appel depuis le navigateur
- Récupération de la requête et création du deuxième socket pour envoyer la requête au serveur web.
- Attente de la réponse du serveur web puis réception des données
- Transfert du bytebuffer en sortie de la socket vers la socket ouverte par le navigateur.
Mon soucis est que je log les HEADER. Donc je lis le contenu du ByteBuffer mais il est souvent tronqué.
Par exemple au lieu d'avoir :
Content-length : 880
Content-type : image/gif
je peux avoir :
Content-length : 880
mage/gis
Je ne vois pas d'où provenir ce décalage dans la lecture... En modifiant la valeur du allocate de 128 à 256 ça décale mais il est toujours présent...
Ca doit venir de mon code. Je fais un clone du ByteBuffer pour que le traitement soit fait dans un Thread mais à première vue le clone n'est pas ressemblant à 100% :(
Je ne comprend rien au buffer.
J'ai une méthode où je parcours mon buffer pour le convertir en String pour récupérer le HEADER de l'objet transmis.
Si je place cette méthode dans un Thread, la lecture est tronquée par endroit alors que cette dernière fonctionne très bien de manière synchrone. J'ai vu que le ByteBuffer n'est pas Thread safe mais je ne vois pas comment le rendre Thread safe... :(
Revoyez votre code.
Si vous avez besoin d'intercepter ce qui passe entre les deux socket via byebuffer, alors vous n'avez plus besoin de bytebuffer. Le principe du bytebuffer c'est justement d'essayer d'éviter le transit des données par la mémoire si c'est possible. Utilisez des socket classiques, elles sont plus facile à manipuler coté contenu.
Question subsidiaire: pourquoi avoir besoin de faire le calcul dans un thread à part?
Je souhaite que l'utilisateur obtienne la réponse à sa requête dans les meilleurs délais donc de placer les calculs de données dans un thread à part pour laisser le proxy terminer son travail.
Merci pour l'info. Je vais voir pour passer par un autre buffer. Dans ce cas, lequel est conseillé ? InputStream et OutputStream ?
D'ailleurs je rajoute une petite question : peut on renvoyer le résultat dans une autre socket en même temps et cette socket est géré par une autre classe du programme ?
ca dépend ce que t'entends par gérer. Le thread à part est inutile et ralentissant. Tu pompe les données dont tu as besoin au passage, dans le thread qui fait le transfert et tu fait tes calculs après. Avec un thread à part tu va pas plus vite puisque, de toutes façons, le thread d'envoi et le thread de calcul sont synchrones.
pour completer la reponse de tchize_ : et en plus d'être synchrones avec une thread en plus tu te rajoutes de permutations de contexte qui sont inutiles.