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 ...