Sockets en Java - Page 2

pokito (./27) :
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.

Il n'y a pas de raison de sectionner le fichier. TCP fonctionne sous forme de flux et les couches supérieures ont, à epsilon près, l'assurance que le transfert est fait sans erreurs. Elles n'ont pas à s'occuper de la problématique d'adaptation de la taille des messages ou à luter contre les erreurs de transmission.

Les "couches supérieures" s'appellent comment ? Et c'est traité à quel niveau le contrôle d'erreur et les demandes de renvoi ?

pokito (./30) :
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 ?

Non, au contraire, ça le multiplie par deux. Au même titre que la BP nécessaire. Et en fonction du dimensionnement de ta connexion, ça peut diviser par deux le débit effectif.

(Je crois que tu as mal lu son post… À priori vous êtes d'accord )

Folco (./32) :
Les "couches supérieures" s'appellent comment ?

L'application.
Enfin, dans [url=http://fr.wikipedia.org/wiki/Modèle_OSI]le modèle OSI[/url], IP est la couche 3, et TCP est la couche 4. Les couches 5, 6 et 7 ne sont pas vraiment utilisées en tant que telles.

Et c'est traité à quel niveau le contrôle d'erreur et les demandes de renvoi ?

C'est une garantie fournie par TCP/IP.
IP fournit comme seule garantie que les paquets IP auront une en-tête valide (l'en-tête indique notamment le protocole…)
Au dessus, TCP s'occupe de la vérification de l'intégrité des données, de la remise en ordre des paquets, et des demandes de retransmission.

folco: les couches supérieures c'est http, ftp, ssh, et tutti quanti.

en gros tcp garantit que tout se passe bien, c'est quasi impossible que les données livrées par TCP soit corrompues à cause du réseau, principalement grâce à des checksums, et des numéros de séquence d'envoi/réception, couplé à des échanges ACK bien foutus qui ne ralentissent pas toute la connexion.

Ca doit être super intéressant tout ça.

Bon alors j'ai un peu avancé.

Je ne saurais pas vraiment l'expliquer mais mes problèmes de sockets qui conprennaient pas que le gars en face avait fini de parler venait des types java que je prenais.

Le problème pour les néophytes comme moi c'est que java propose 15 000 classes plus ou ou moins bas niveau en fonction du type de données, et je ne me souviens plus du type que j'utilisait mais ce n'était pas le bon.

Maintenant je lis et j'écrit dans un DataInputStream/DataOutputStream et ça va beaucoup mieux.

Sinon pour le reste, toutes les strings passées "en clair" sont bien en UTF16-LE. Les bouts de binaires qui se baladent sont des bouts de GZip qu'il suffit d'empiler dans un fichier pour obtenir un fichier tout propre et tout dézippable (contenant lui même pleins de texte en UTF16-LE.

Bref merci de votre aide, j'ai finit d'implémenter ma classe de dialogue avec le serveur (les checksums qui passent sont des CRC32 btw), et j'enterre déjà la solution existante niveau perf (1min55 au lieu de 12 min pour un échange de fichier).

squalyl (./35) :
folco: les couches supérieures c'est http, ftp, ssh, et tutti quanti.

en gros tcp garantit que tout se passe bien, c'est quasi impossible que les données livrées par TCP soit corrompues à cause du réseau, principalement grâce à des checksums, et des numéros de séquence d'envoi/réception, couplé à des échanges ACK bien foutus qui ne ralentissent pas toute la connexion.

Et je rajouterai qu'en pratique, ouvrir une socket TCP/IP revient plus ou moins à se retrouver avec un objet (un descripteur de fichier) avec une méthode read et une méthode write, en espérant qu'à l'autre bout, ton correspondant a fait la même chose.
Quand tu utilises la méthode write(), ça envoie les données via le réseau et le correspondant utilisera la méthode read() pour les lire.

Tu n'as pas à te préoccuper de la validité des données transmises (c'est TCP qui s'en charge, grosso-modo en récupérant les paquets IP reçus et en les remettant dans l'ordre), ni à déterminer la taille des paquets à envoyer ou à quel intermédiaire les envoyer (ça, c'est IP qui s'en charge), et encore moins comment les transmettre suivant le moyen physique (ethernet, wifi, ...).