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 ?

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 ?

31

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

32

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

33

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.
avatar
Webmaster du site Ti-FRv3 (et aussi de DevLynx)
Si moins de monde enculait le système, alors celui ci aurait plus de mal à nous sortir de si grosses merdes !
"L'erreur humaine est humaine"©Nil (2006) // topics/6238-moved-jamais-jaurais-pense-faire-ca

34

(Je crois que tu as mal lu son post… À priori vous êtes d'accord cheeky)
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.
avatar
Le scénario de notre univers a été rédigée par un bataillon de singes savants. Tout s'explique enfin.
T'as un problème ? Tu veux un bonbon ?
[CrystalMPQ] C# MPQ Library/Tools - [CrystalBoy] C# GB Emulator - [Monoxide] C# OSX library - M68k Opcodes

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.

36

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

37

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

38

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, ...).
avatar
<<< Kernel Extremis©®™ >>> et Inventeur de la différence administratif/judiciaire ! (©Yoshi Noir)

<Vertyos> un poil plus mais elle suce bien quand même la mienne ^^
<Sabrina`> tinkiete flan c juste qu'ils sont jaloux que je te trouve aussi appétissant