15Fermer17
pokitoLe 03/11/2012 à 01:07
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 ...