Sockets en Java - Page 1

Bon commencer puisque c'est supposé être over easy les sockets en Java

!call squalyl

Bon alors je suis en train de regarder comment fonctionne le dialogue entre un client et un serveur et de recoder le protocole côté client. DOnc pour ça je fais des tests avec mon client existant, je regarde ce qui se dit avec Wireshark, et je fais pareil avec mon client Java.

Le problème que j'ai à l'heure actuelle c'est que les mecs qui ont dévellopé ça n'ont pas suivi les 2 grandes façons de faire un petit protocole :

- La première solution consiste en règle générale à envoyer la taille du paquet en premier, comme ça on sait à quoi s'attendre. Ils l'ont pas fait.
- La seconde solution c'est de mettre un caractère ou une séquence qui finit le message. Ils l'ont pas fait non plus. (pas même un \n ...)

Du coup la question est "comment font ils" ? A priori en matant les entêtes IP et TCP c'est possible d'en déduire quelle sera la taille à lire, mais là pour le coup je sais pas faire. Wireshark me dit bien gentillement qu'il a trouvé tout seul combien de bytes sont en jeu (avec un sublime "Bytes in flight").

Bref :

1/ Vous avez déjà vu des protocoles qui fonctionnent comme ça ?
2/ Vous auriez pas des idées tordues de comment ça pourrait fonctionner en fait ?
3/ Vous savez comment on trifouille les packets en aussi bas niveau que Wireshark avec Java ?
4/ Vous avez une super bonne idée qui me permette de contourner le problème ? Mon read() sur le InputStream attend misérablement une nouvelle info et je sais pas comment lui dire que c'est bon, tout est sous contrôle.

Et à priori ils font ça pour les envoi de commande ET pour les envoi de fichiers :/

Tu parles de TCP, mais tu es sûr que c'est ce qui est utilisé ? Normalement TCP fonctionne sous forme de flux, il faut donc comme tu l'écris repérer les débuts et fins des messages (au sens de ton protocole). Certains l'utilisent sans s'en soucier car le tampon de réception sera lu avant l'arrivée du message suivant, et qu'ils sont donc délimités par des délais, c'est peu fiable. Tu peux avoir la taille de ton message simplement en regardant la taille de ce que te retourne la fonction de lecture.

Sinon, si c'est de l'UDP, bah la taille est donnée dans l'entête IP du datagramme non fragmenté.

1/ Vous avez déjà vu des protocoles qui fonctionnent comme ça ?

t'as oublié la 3e grande méthode pour faire un protocole, le caractère séparateur + échappement de cet octet si il apparait dans le message. Le modèle c'est HDLC, par exemple séparateur 0x7E et si 0x7E apparait dans le message, on l'échappe en 0x7D 0x5E, et 0x7D est échappé en 0x7D 0x5D. y'a d'autres possibilités.

2/ Vous auriez pas des idées tordues de comment ça pourrait fonctionner en fait ?

comme je viens de te dire, ça a été une mode à une époque, parce que c'est autosynchronisant.

3/ Vous savez comment on trifouille les packets en aussi bas niveau que Wireshark avec Java ?

non ça je crois pas que ça existe

4/ Vous avez une super bonne idée qui me permette de contourner le problème ? Mon read() sur le InputStream attend misérablement une nouvelle info et je sais pas comment lui dire que c'est bon, tout est sous contrôle.

il te faut du read non bloquant. Soit avec les FileChannel soit en réglant les timeouts de tes sockets, plus simple. read retournera même si y'a rien à lire.

pokito (./1) :
1/ Vous avez déjà vu des protocoles qui fonctionnent comme ça ?

Je suis pas uin expert réseau, mais il me semble qu'en TCP-IP c'est la norme. On ouvre un flux on balance et on ferme. Le protocole se charge de tout le reste.

pokito (./1) :
3/ Vous savez comment on trifouille les packets en aussi bas niveau que Wireshark avec Java ?

C'est pas possible en pur Java.

pokito (./1) :
4/ Vous avez une super bonne idée qui me permette de contourner le problème ? Mon read() sur le InputStream attend misérablement une nouvelle info et je sais pas comment lui dire que c'est bon, tout est sous contrôle.

Normalement un read() doit retourner -1 quand il atteint la fin du flux.

Merci de toutes ces réponses !

Alors pour reprendre dans l'ordre :

RHJPP (./3) :
Tu parles de TCP, mais tu es sûr que c'est ce qui est utilisé ?

Oui, j'en suis bien sûr (Wireshark + test perso le montre bien). En fait là je dialogue avec le serveur en TCP, c'est juste que pour lire sa réponse il faut que je regarde dans wireshark parce que ça remonte pas dans mon prog java ^^

squalyl (./4) :
t'as oublié la 3e grande méthode pour faire un protocole, le caractère séparateur + échappement de cet octet si il apparait dans le message. Le modèle c'est HDLC, par exemple séparateur 0x7E et si 0x7E apparait dans le message, on l'échappe en 0x7D 0x5E, et 0x7D est échappé en 0x7D 0x5D. y'a d'autres possibilités.

Ah oui, en fait c'est une variation de ma méthode 2 mais qui permet d'utiliser le séparateur dans le paquet. Je retiens pour plus tard. Mais ici les paquet ont une fin assez abrupte ...

squalyl (./4) :
non ça je crois pas que ça existe

squalyl (./4) :
il te faut du read non bloquant. Soit avec les FileChannel soit en réglant les timeouts de tes sockets, plus simple. read retournera même si y'a rien à lire.

Oui les timeout sont une bonne idée mais faudra que je regarde de plus près comme c'est censé tourner en 2G/3G/wifi/LAN, histoire de pas avoir de mauvaise surprise ... Genre voir à quel point le serveur peut devenir "lent" sur une connexion de merde. Je regarde les FileChannel avec attention et je reviens.

Uther (./5) :
Je suis pas uin expert réseau, mais il me semble qu'en TCP-IP c'est la norme. On ouvre un flux on balance et on ferme. Le protocole se charge de tout le reste.

En fait dans le cas particulier, j'ouvre un flux mais je ne le referme pas. Je suis sur une couche supérieure au protcole TCP/IP en fait. Il y a une taille limite où les paquets vont commencer à se scinder tout seul (j'ai pas encore fait de test avec des gros fichiers) et c'est là que la magie du TCP va jouer pour moi. Mais en Java c'est transparent tout ça (je suis sur une couche supérieure) et normallement on réimplémente un moyen de connaitre la taille du transfert à la sortie.

Uther (./5) :
Normalement un read() doit retourner -1 quand il atteint la fin du flux.

Oui, mais là il se bloque car il ne détecte pas la fin du flux, rien d'autre.

Un petit paquet pour les fans :

Partie "Data" de longueur 40 qui vient après le header.

0000   4f 00 2c 00 22 00 52 00 65 00 61 00 64 00 79 00  O.,.".R.e.a.d.y.
0010   20 00 74 00 6f 00 20 00 75 00 70 00 6c 00 6f 00   .t.o. .u.p.l.o.
0020   61 00 64 00 21 00 22 00                          a.d.!.".

Comme vous le voyez ils ont trouvé ça cool de mettre des "null" entre toutes les lettres. Ça a sans doute une justification, genre pouvoir checker en live si y'a pas un décalage.

Et le header TCP :

0000   21 98 10 bd d0 44 ec cc d6 4b d0 26 50 18 fa 8e  !....D...K.&P...
0010   54 ab 00 00                                      T...

Je vous mets pas le header IP ou le header Ethernet parce que je ne crois pas que ça serve à grand chose ...

pokito (./7) :
Comme vous le voyez ils ont trouvé ça cool de mettre des "null" entre toutes les lettres. Ça a sans doute une justification, genre pouvoir checker en live si y'a pas un décalage.

Je pense plutôt que c'est de l'UTF-16.

Ce que tu dis a du sens. Mais le premier "O" est codé 4f et pas 00 4f. Et on fini tout par un 00 aussi. Du coup je doute un peu.

pokito (./6) :
Un petit paquet pour les fans :

Partie "Data" de longueur 40 qui vient après le header.

0000   4f 00 2c 00 22 00 52 00 65 00 61 00 64 00 79 00  O.,.".R.e.a.d.y.
0010   20 00 74 00 6f 00 20 00 75 00 70 00 6c 00 6f 00   .t.o. .u.p.l.o.
0020   61 00 64 00 21 00 22 00                          a.d.!.".

2c ça fait 44, c'est pas la taille de la chaine en octets + la taille du simili header "4f 00 2c 00" ?

big endian <=> little endian ?

(./9 ah non, zut, c'est dans l'autre sens (mais bon, tu peux toujours vérifier, on sait jamais ))

Pen^2 > Oui, mais où tu le vois le 2f ? La partie data commence avec un 4f, qui donne un "O" comme "OK".

Ils sont très friands de première lettre qui sert de commande. Genre R pour réplication, C pour contrôle, D pour dispatch, T pour statut (pas sûr pour celui-ci ). En fin de communication, j'ai un nouveau paquet qui revient avec un "O" de taille différente, avant un timestamp.

Pour l'instant je me garde les timeout sous la main au cas où mais je trouve pas ça "propre" (si ça se trouve c'est ce qu'ils ont mis côté serveur ...).

squalyl > Toi qui a déjà un peu touché au GPRS/3G, tu conseilles quoi comme timeout pour pas être trop violent sans être trop lent ? 200ms je me rend pas compte si c'est énorme ...

Sinon bien évidemment je ne rien tester de chez moi parce que le serveur n'est pas accessible au public, et je n'ai pas de login vpn ...

vince > Je refuse d'avoir encore à faire à ces conneries de big endian/little endian, ça m'a déjà fait perdre une bonne semaine cet été ^^ (j'avais une image en big endian sur 16 bits et forcément toutes les visionneuses me l'ouvrait en little endian, du coup je comprenais pas pourquoi la disparity map de la caméra stéréoscopique du labo ne fonctionnait pas ^^).

edit : cross

J'ai édité, c'est 2c, pas 2f. 0x2c=44 et donc pas 40
Tu sais à quoi ça sert ce 2c ? Sur d'autres paquets ça donne quoi ?

pokito (./6) :
Oui, mais là il se bloque car il ne détecte pas la fin du flux, rien d'autre.

Donc si je comprend bien, le serveur ne ferme pas la connexion quand il a terminé?
Dans ce cas là, il faut voir si dans le protocole, tu ne peux pas déterminer une règle dans les données envoyées pour fermer la connexion toi même. Par exemple dans ta chaine, il semblerait que le guillemet fermant pourrait être une solution, reste a voir si c'est généralisable.
C'est probablement ce que fait déjà ton client actuel, car même en C faire ce que tu veux faire, c'est moche.

pokito (./6) :
Comme vous le voyez ils ont trouvé ça cool de mettre des "null" entre toutes les lettres. Ça a sans doute une justification, genre pouvoir checker en live si y'a pas un décalage.

6 LittleEndian. Si tu veux lire ça en java utilise un reader: Reader r = new InputStreamReader(inputStream, "UTF-16LE");Comme le dit Zerosquare, c'est plus probablement de l'utf-1

C'est pas simplement ce format : C,"Données"
Où C est un code ? Il faudrait d'autres exemples pour savoir.

Ah oui, ça c'est fort possible (j'avais pas capté que le little/big endian de vince se référait à l'utf16).

Mais qui écrit des données en utf16-LE pour envoyer des commandes à un serveur, sérieusement ? Y'a genre 4 commandes différentes, parce que dès qu'on passe aux données c'est zippé avant d'être transféré, le client est codé sur du windows mobile 5.0 avec du .NET 1.1, et ça gérait nativement l'utf16-LE à cette époque là ou c'est une lubie à eux de la rajouter à la main ? C'est vraiment écraser une mouche avec une enclume ...

Je ferais le test lundi. En attendant j'avais le coup naïf de rajouter \0 après chaque caractère pour encoder et de l'enlever pour décoder. Tant qu'on reste sur de l'ascii, ça aurait bien fonctionné ^^

Uther > Pour le coup de la fermeture de la communication, tu veux parler des paquets ou des sockets ? Parce que les sockets c'est normal de jamais les fermer. C'est comme des pipes, si on s'amusait à les ouvrir et à les fermer à chaque fois on aurait pas fini. Par contre le packet, je sais pas comment c'est censé se fermer, y'a peut être un EOF que wireshark n'indique pas.

Ensuite, Wireshark me découpe bien les paquets, mais je ne sais pas non plus comment il fait. Soit y'a vraiment un EOF qui est envoyé et qui devrait me faire un read() qui vaut -1 et j'ai fait une merde dans mon code, soit il se base sur le reste de la communication ou sur la couche TCP.

Pour les timeout, tu as raison, c'est franchement très crade ...

pokito (./16) :
Mais qui écrit des données en utf16-LE pour envoyer des commandes à un serveur, sérieusement ?

le client est codé sur du windows mobile 5.0 avec du .NET 1.1,

Tu as répondu à ta propre question.

et ça gérait nativement l'utf16-LE à cette époque là

Oui, tout est en UTF-16 à Redmond.

ou c'est une lubie à eux de la rajouter à la main ? C'est vraiment écraser une mouche avec une enclume ...

C'est le plus simple pour eux parce que leur plateforme leur donne nativement de l'UTF-16.

Uther > Pour le coup de la fermeture de la communication, tu veux parler des paquets ou des sockets ? Parce que les sockets c'est normal de jamais les fermer. C'est comme des pipes, si on s'amusait à les ouvrir et à les fermer à chaque fois on aurait pas fini. Par contre le packet, je sais pas comment c'est censé se fermer, y'a peut être un EOF que wireshark n'indique pas.
Ensuite, Wireshark me découpe bien les paquets, mais je ne sais pas non plus comment il fait. Soit y'a vraiment un EOF qui est envoyé et qui devrait me faire un read() qui vaut -1 et j'ai fait une merde dans mon code, soit il se base sur le reste de la communication ou sur la couche TCP.

Bah, la taille est fournie par le header TCP, il n'y en a pas besoin dans le protocole (et Wireshark ne comprend pas ce protocole propriétaire, donc forcément il s'appuyerait de toute façon sur le header TCP qu'il comprend).

./15 > Si si c'est bien ça ^^

Bon pour vos beaux yeux :

Etape 1 de la connexion :

0000   52 00 5f 00 4f 00 52 00 4b 00 5f 00 54 00 4d 00  R._.O.R.K._.T.M.
0010   50 00 2c 00 22 00 50 00 4b 00 47 00 55 00 50 00  P.,.".P.K.G.U.P.
0020   4c 00 4f 00 41 00 44 00 22 00 2c 00 22 00 53 00  L.O.A.D.".,.".S.
0030   65 00 72 00 76 00 69 00 63 00 65 00 77 00 61 00  e.r.v.i.c.e.w.a.
0040   72 00 65 00 22 00 2c 00 22 00 44 00 41 00 54 00  r.e.".,.".D.A.T.
0050   41 00 50 00 4b 00 47 00 46 00 49 00 4c 00 45 00  A.P.K.G.F.I.L.E.
0060   22 00                                            ".

==> Pour moi c'est une demande de replication (R) avec le code du technicien "_ORK_TMP" attaché pour identifier l'utilisateur. Ensuite c'est des chaines pour dire quel format on veut.

Etape 2 : Le serveur répond !

0000   4f 00 2c 00 22 00 52 00 65 00 61 00 64 00 79 00  O.,.".R.e.a.d.y.
0010   20 00 74 00 6f 00 20 00 75 00 70 00 6c 00 6f 00   .t.o. .u.p.l.o.
0020   61 00 64 00 21 00 22 00                          a.d.!.".

==> Ça c'est bizarre en fait. Parce que rien n'est jamais envoyé par le serveur comme donnée dans cette procédure. Ca veut dire, je suis prêt à ce que TU upload mais c'est pas vraiment ce qui est écrit.

Etape 3 : Le PDA répond par ça :

0000   44 00 50 00 41 00 43 00 4b 00 41 00 47 00 45 00  D.P.A.C.K.A.G.E.
0010   55 00 4c 00 2c 00 55 00 2c 00 22 00 50 00 4b 00  U.L.,.U.,.".P.K.
0020   47 00 4f 00 4e 00 45 00 4f 00 4e 00 4c 00 59 00  G.O.N.E.O.N.L.Y.
0030   22 00 2c 00 1f 8b 08 00 00 00 00 00 00 0b 3d 8b  ".,...........=.
0040   b1 0e 40 30 18 84 bf ad 42 fb 12 9d bd 84 84 09  ..@0....B.......
0050   25 2d b3 88 74 b0 1a 78 7d 67 91 1b ee ee fb ef  %-..t..x}g......
0060   8f 6c 4c 44 7a f9 c2 c8 4c 8d 67 95 0f e2 0d ad  .lLDz...L.g.....
0070   da 47 12 99 8b 9b 93 43 e9 61 57 cb ff ad 23 68  .G.....C.aW...#h
0080   99 f4 e1 31 14 58 2a 1c a5 e4 94 ac 88 e1 05 8b  ...1.X*.........
0090   f8 8d cc 6a 00 00 00                             ...j...

==> Dispatch des infos du PDA sur le serveur.

Etape 4 : Le serveur confirme la réception :

0000   43 00 31 00 35 00 31 00 2c 00 22 00 32 00 34 00  C.1.5.1.,.".2.4.
0010   33 00 32 00 34 00 36 00 35 00 39 00 30 00 22 00  3.2.4.6.5.9.0.".
0020   2c 00 22 00 32 00 34 00 33 00 32 00 34 00 36 00  ,.".2.4.3.2.4.6.
0030   34 00 34 00 31 00 22 00                          4.4.1.".

==> C pour controle. 151 c'est la taille du paquet précédent (vérifié sur d'autres discussions entre les deux, le chiffre après C est toujours la taille du paquet précédent reçu). Par contre la clef d'après, NO IDEA. Si vous avez des suggestions.

Etape 5 : Le PDA répond :

0000   54 00 2c 00 22 00 54 00 72 00 61 00 6e 00 73 00  T.,.".T.r.a.n.s.
0010   6d 00 69 00 73 00 73 00 69 00 6f 00 6e 00 20 00  m.i.s.s.i.o.n. .
0020   64 00 65 00 73 00 20 00 69 00 6e 00 74 00 65 00  d.e.s. .i.n.t.e.
0030   72 00 76 00 65 00 6e 00 74 00 69 00 6f 00 6e 00  r.v.e.n.t.i.o.n.
0040   73 00 20 00 74 00 65 00 72 00 6d 00 69 00 6e 00  s. .t.e.r.m.i.n.
0050   e9 00 65 00 2e 00 20 00 28 00 32 00 36 00 29 00  ..e... .(.2.6.).
0060   22 00                                            ".

==> Pour lui c'est fini.

Etape 6 : le serveur dit OK :

0000   4f 00 2c 00 22 00 32 00 30 00 31 00 32 00 31 00  O.,.".2.0.1.2.1.
0010   30 00 33 00 31 00 31 00 35 00 33 00 35 00 30 00  0.3.1.1.5.3.5.0.
0020   39 00 22 00                                      9.".

==> O pour OK puis le timestamp de la MAJ.

Et ça c'est un UPLOAD des informations du PDA vers le serveur. Ensuite y'a presque le symétrique qui intervient pour télécharger sur le PDA les données que le serveur veut lui envoyer.

KK > Alors là je savais pas du tout que Microsoft méttait de l'UTF16 partout, du coup je comprends bien mieux (pour moi l'UTF16 c'était pour ceux qui étaient pas assez jouasses avec l'UTF8 qui a déjà l'air de faire le boulot ^^).

Merci pour ces précisions !

Pour Wireshark, bien entendu qu'il ne repose pas sur le protocole du serveur. Mais pour autant la taille du paquet TCP n'a pas l'air d'être donnée en clair dans le header contrairement à l'UDP.

Le calcul de la taille de DATA donnée à la fin de la couche TCP par Wireshark repose en fait sur le ACK envoyé par l'autre interlocuteur lors de la réception du paquet.

Wireshark t'affiche le contenu des datagrammes et pas le flux lui-même. Donc comme un message semble généralement tenir dans un datagramme et qu'il est tout seul, bah tu les vois séparés les uns des autres.

pokito (./18) :
Etape 4 : Le serveur confirme la réception :

0000   43 00 31 00 35 00 31 00 2c 00 22 00 32 00 34 00  C.1.5.1.,.".2.4.
0010   33 00 32 00 34 00 36 00 35 00 39 00 30 00 22 00  3.2.4.6.5.9.0.".
0020   2c 00 22 00 32 00 34 00 33 00 32 00 34 00 36 00  ,.".2.4.3.2.4.6.
0030   34 00 34 00 31 00 22 00                          4.4.1.".

243246590 - 243246441 = 149 = 151 - 2
Une taille ? Mémoire allouée restante ?

pokito (./18) :
Etape 6 : le serveur dit OK :

0000   4f 00 2c 00 22 00 32 00 30 00 31 00 32 00 31 00  O.,.".2.0.1.2.1.
0010   30 00 33 00 31 00 31 00 35 00 33 00 35 00 30 00  0.3.1.1.5.3.5.0.
0020   39 00 22 00                                      9.".

Là, c'est la date, mais tu l'avais surement vu

pokito (./12) :
j'ai un nouveau paquet qui revient avec un "O" de taille différente

Essaye de voir si c'est pas un "o" des fois. J'ai encore un doute, mais ça pourrait être ça.

RHJPP (./20) :

pokito (./18) :
Etape 6 : le serveur dit OK :
0000 4f 00 2c 00 22 00 32 00 30 00 31 00 32 00 31 00 O.,.".2.0.1.2.1. 0010 30 00 33 00 31 00 31 00 35 00 33 00 35 00 30 00 0.3.1.1.5.3.5.0. 0020 39 00 22 00 9.".

Là, c'est la date, mais tu l'avais surement vu

C'est pour ça que j'ai mis que c'était le timestamp ^^

Pour la soustraction, oui j'avais vu ça, mais dans certains autres échanges (notamment lorsqu'on DL au lieu d'UL à partir du PDA), on a un seul des 2 chiffre ...

Genre, le serveur envoi un fichier (ça vient de la suite que j'ai pas posté quand on fait plus un UL mais un DL):

0000   44 00 52 00 65 00 70 00 50 00 61 00 63 00 6b 00  D.R.e.p.P.a.c.k.
0010   65 00 74 00 2c 00 53 00 2c 00 1f 8b 08 00 00 00  e.t.,.S.,.......
0020   00 00 00 0b 4d 8a bd 0e 40 40 10 84 bf ee 84 f3  ....M...@@......
0030   12 57 2b 1c a1 97 5c a3 d0 08 51 23 3a 85 c2 fb  .W+...\...Q#:...
0040   c7 f8 29 64 b3 33 bb df 4c a0 67 e3 a0 61 e5 a4  ..)d.3..L.g..a..
0050   25 90 31 6a 1d 1d d3 97 dd d4 3d ec df 1d 98 59  %.1j......=....Y
0060   d8 45 de ac 20 c7 4b bd bc 94 7a 6a 79 f5 fc 0e  .E.. .K...zjy...
0070   43 84 25 21 25 d6 a4 ba ac 88 e1 02 8c 63 c1 bb  C.%!%........c..
0080   80 00 00 00                                      ....

Et le PDA renvoit :

0000   43 00 31 00 33 00 32 00 2c 00 22 00 32 00 33 00  C.1.3.2.,.".2.3.
0010   33 00 33 00 39 00 38 00 39 00 37 00 34 00 39 00  3.3.9.8.9.7.4.9.
0020   22 00                                            ".

==> On a bien le 132 qui correspond au 132 bytes mais on a qu'un seul chiffre là ...

Folco (./21) :

pokito (./12) :
j'ai un nouveau paquet qui revient avec un "O" de taille différente

Essaye de voir si c'est pas un "o" des fois. J'ai encore un doute, mais ça pourrait être ça.

Oui c'est bien un O : "4f 00"

Premier message :

0000   4f 00 2c 00 22 00 52 00 65 00 61 00 64 00 79 00  O.,.".R.e.a.d.y.
0010   20 00 74 00 6f 00 20 00 75 00 70 00 6c 00 6f 00   .t.o. .u.p.l.o.
0020   61 00 64 00 21 00 22 00                          a.d.!.".

Deuxième message :

0000   4f 00 2c 00 22 00 32 00 30 00 31 00 32 00 31 00  O.,.".2.0.1.2.1.
0010   30 00 33 00 31 00 31 00 35 00 33 00 35 00 30 00  0.3.1.1.5.3.5.0.
0020   39 00 22 00                                      9.".

Troisième message à la fin :

0000   4f 00 2c 00 22 00 32 00 30 00 31 00 32 00 31 00  O.,.".2.0.1.2.1.
0010   30 00 33 00 31 00 31 00 35 00 33 00 35 00 31 00  0.3.1.1.5.3.5.1.
0020   30 00 22 00                                      0.".

C'est à chaque fois des 4f 00, et deux fois c'est suivi d'un timestamp, l'autre fois c'est un message "human readable".

pokito (./22) :
C'est pour ça que j'ai mis que c'était le timestamp ^^

Ha oui, en effet

pokito (./22) :
Pour la soustraction, oui j'avais vu ça, mais dans certains autres échanges (notamment lorsqu'on DL au lieu d'UL à partir du PDA), on a un seul des 2 chiffre ...

Il faudrait voir au fil des échanges comment ça évolue. Si les valeurs données par le serveur sont liées à celles du client...

Oui je vais faire plus de test là dessus lundi. Je bien regarder partout si y'a pas cette info qui traine sur ou dans le fichier UL ou DL.

(c'est trop mignon ces gens qui font du human-readable pour des communications client/serveur... à croire que plus personne ne connaît le binaire )

Vu les paquets donnés comme exemples, pas besoin d'avoir une taille de paquet pour parser le protocole :

R<code technicien>,"...","...","..."
O,"..."

DPACKAGEUL,U,"...",<payload>
CXXX,"...","..."

DRepPacket,S,<payload>
CXXX,"..."

T,"..."

Il ne reste plus qu'à analyser le format des payload (qui manifestement ont un header identique de 10 octets, et un nombre 32-bit little endian à la fin), mais il en faudrait plusieurs (dans les deux sens) pour savoir si ils ont systématiquement la même taille ou pas.

0² > En fait je crois que certains messages sont affichés sur le PDA mais pas tous (et y'en a qui sont rajoutés !). Donc ça serait pour laisser du paramétrage.

Le problème c'est que pour le R par exemple, j'ai posté la demande d'UL du PDA.

Mais quand le PDA demande à DL ça fait :

0000   52 00 5f 00 4f 00 52 00 4b 00 5f 00 54 00 4d 00  R._.O.R.K._.T.M.
0010   50 00 2c 00 22 00 50 00 4b 00 47 00 44 00 4f 00  P.,.".P.K.G.D.O.
0020   57 00 4e 00 4c 00 4f 00 41 00 44 00 22 00 2c 00  W.N.L.O.A.D.".,.
0030   22 00 53 00 65 00 72 00 76 00 69 00 63 00 65 00  ".S.e.r.v.i.c.e.
0040   77 00 61 00 72 00 65 00 22 00 2c 00 22 00 52 00  w.a.r.e.".,.".R.
0050   45 00 50 00 4c 00 49 00 43 00 41 00 54 00 49 00  E.P.L.I.C.A.T.I.
0060   4f 00 4e 00 22 00 2c 00 22 00 4d 00 57 00 52 00  O.N.".,.".M.W.R.
0070   65 00 70 00 49 00 44 00 22 00 2c 00 22 00 32 00  e.p.I.D.".,.".2.
0080   30 00 31 00 32 00 31 00 30 00 33 00 31 00 31 00  0.1.2.1.0.3.1.1.
0090   36 00 33 00 31 00 31 00 32 00 22 00 2c 00 22 00  6.3.1.1.2.".,.".
00a0   31 00 34 00 2e 00 31 00 2e 00 35 00 2e 00 34 00  1.4...1...5...4.
00b0   22 00                                            ".

Donc R<code tech>, "...", "...", "...", "...", "...", "..."

Pour le payload j'ai pas regardé, mais à priori c'est un seul fichier zip, et parfois le fichier commence à grossir, donc je pense que c'est mis dans au moins 2 packets. Ca serait une entête ZIP (je sais pas comment c'est fait ces bêbêtes là ...) peut être.

un entête zip c'est PK mais y'a pas de zéros entre les deux.

la raison de ton utf-16 c'est windows mobile, qui fait tout en unicode. donc char est remplacé par wchar_t qui est un unsigned short little endian.

./25 > C'est clair… On voit le protocole étudié pour une très haute inefficacité réseau -_-
Je ne sais pas quel logiciel produit cette merde, mais j'espère ne jamais l'utiliser

pokito (./19) :
KK > Alors là je savais pas du tout que Microsoft méttait de l'UTF16 partout, du coup je comprends bien mieux (pour moi l'UTF16 c'était pour ceux qui étaient pas assez jouasses avec l'UTF8 qui a déjà l'air de faire le boulot ^^).

Non, tu ne comprends rien mieux, KK raconte sa merde habituelle. La représentation de l'Unicode en mémoire es effectivement UTF-16 sous Windows, mais Microsoft n'a jamais conseillé à personne d'utiliser de l'UTF-16 pour concevoir un protocole réseau, pas plus qu'il ne te force à enregistrer tes fichiers texte en UTF-16, ou que sais-je. C'est purement un choix des abrutis qui ont développé le logiciel (Pour référence, en .NET, l'encodage par défaut des flux est UTF-8. C'est pas toujours l'idéal, mais la décision finale appartient aux développeurs…)

Ok, par contre passer à de l'utf8 pour faire transférer de l'ASCII au final, on est bien d'accord que ça divise par 2 le trafic ?

squalyl > Là je commence par 1f 8b 08 mon fichier, et selon : http://www.garykessler.net/library/file_sigs.html c'est du "GZ, TGZ, GZIP archive file". Par contre y'a pas de raison que mon fichier zip soit en utf16-le, non ?