djes a écrit :TCP va s'occuper de tout recoller (...) C'est à toi d'interpréter les paquets rentrants pour savoir ce que tu vas recevoir et gérer tout ça
J'ai du rater un truc...
- Il s’appelle Juste Leblanc
- Mais... Il a pas de prénom?
- Je viens de vous le dire: Juste Leblanc!
- ...
Imaginons que tu aies 128Koà envoyer. Tu découpes en morceaux de 64Ko et tu envoies. TCP va s'arranger pour qu'à l'arrivée tes morceaux de 64Ko arrivent, point, quel que soit le nb de paquets utilisés par IP et le chemin emprunté. C'est à toi ensuite de recoller les morceaux de 64Ko.
Et moi je confirme bien que j'ai indiqué 64 méga dans ma taille de gabarit, et que c'est une valeur qui, à voir le code en bout de lien de Djes, ma valeur de taille de gabarit est complètement... euh ... fausse. C'est une sécurité bien au-delà de la réalité. Réalité que je découvre, comme qui dirait, en direct (merci Djes pour cet entartage).
Une analogie parfaite pour cerner le transfert réseau : un livre.
Quand on lit un livre (assidûment), on tourne les pages.
Le texte est divisé en pages. La division des pages est la division matérielle d'un réseau. Cette division-là n'a pas à être gérée, mais à seulement être contrôlée.
Et cette division n'a rien à voir avec la division des paragraphes dans le livre. Cette division des paragraphes représente une des divisions virtuelles : celle qu'il te faut gérer, en considérant qu'un paragraphe de lecture d'un livre peut être court, comme long, voire très long et occuper plusieurs pages.
Le caractère <?> semble être comme un saut de ligne de séparation de paragraphe de lecture d'un livre.
Je viens de vérifier pour en avoir le coeur net: les 65536 octets maximum par paquet c'est dû au protocole TCP qui code la longueur de ses paquets sur 16 bits.
Le plus grand chiffre qu'il est possible d’écrire dans 16 bit est 65536. CQFD
(source, page 21, TCP header, window size)
C'est donc une limite protocolaire (qu'il est apparemment possible de dépasser, mais bref... la norme c'est 65536) et, en PureBasic, c'est à nous de gérer la taille/découpe/assemblage des paquets.
Le TCP s'assure 'juste' que tous les paquets arrivent à destination entiers et dans le bon ordre.
Pour mon cas c'est donc bien le serveur qui découpe les frames websocket qu'il m'envoit, et qui ajoute quelques caractères pour marquer la coupe bien que ce ne soit pas nécessaire grâce au protocole TCP et qui ne l'indique pas dans la doc, ce qui casse bien les pieds aux codeurs noobs PARCE QUE LES JSON DECONNENT ET LES TAILLES CORRESPONDENT PAS! sa*op de serveur...
Bon, ceci dit, le problème à été résolu (ou plutôt contourné), merci à tous!
(ça serait quand même bien une option dans PeekS() pour ignorer le caractère #NULL...)
1* Je n'ai pas accès au source PDF. Mais s'il est écrit que la taille s'étale sur 2 octets, 16 bits, alors prenons ça pour acquis (ou acquit). Aussi, je dois être un des seuls "actifs" ici à ne pas avoir accès à ce pdf. Donc merci, car je pense fortement (et aveuglément) que c'est enrichissant d'apporter de telles sources.
Petite remarque : la base de comptage, 0 ou 1. C'est le détail qui offre d'éventuels bugs. Avec 4 bits, on a 16 combinaisons possibles (mesures quantitatives, basées à 1), et on peut compter jusqu'à 15 (mesures qualitatives, basées à 0). J'avais mal précisé ça aussi. La valeur dans la structure du gabarit n'est pas vérifiée par rapport à ça.
Pour les chiffres un peu insignifiants, ça reste important de les connaître. Il me semble qu'il doit y avoir deux sommes de contrôle, notamment, ainsi qu'un TTL d'effet (Time To Live) pour savoir le nombre de noeuds parcourus par le paquet entre le point d'émission et le point de réception et un TTL de consigne rapporté pour faire le soustraction. Ça peut être important de disposer d'un log chronométré avec ces valeurs archivées pour tirer le vrai du faux en cas d'interférences réseau, de quelque nature soient-elles, pour des flux sensibles.
2* Pour JSon, je ne sais pas. C'est du texte avec une syntaxe précise a priori assez simple. En tout cas, il semble qu'il y a des subtilités de syntaxe dans le JSon : il faut réfléchir << robot low cost >> pour le comprendre. Sur le site PureBasic EN/US, il y a quelques questions anecdotiques avec réponses sur le JSon.
3* Le PeekS() à zéro terminal est imposé. C'est-à-dire que c'est la norme. Pourquoi une telle bévue ? Je suppose que, parce que Microsoft (le fondateur) s'est fait piquer la vedette en 1987 avec les chaînes à quantité déterminée par 15 bits (signés) alors qu'ils disposaient des deux types de chaînes (le nul string pour les pipes) pour 8 bits, et qu'ils se faisaient imposer les chaînes à quantité déterminée par 8 bits, par les fabricants, pour se la sentir bien établie dans le succès grandissant, et s'adapter à des chaînes supérieures à 255 caractères, ils n'ont rien trouvé de plus simple et arrogant que de répandre ce système. Avec l'avènement de l'Unicode, la blague est à peine voilée, puisque le système de taille de chaîne à 15 bits est encore largement tout puissant 31 ans plus tard, permettant des chaînes de 32767 caractères avec, pour cerise sur le gateau l'utilisation possible de mixer les deux techniques en utilisant le bit de signe de la quantité : si 1, rebelote, sinon fin de chaîne (donc taille de chaîne infinie).
Ça semble une bonne idée le PeekS étendu à ça. Mais du texte c'est sensible, et rajouter une condition là, ça peut laguer. C'est plus performant de créer une autre instruction, voire un autre jeu complet d'instructions. C'est pour ça que j'ai déballé cette histoire de gabarit : c'est la méthode-clé pour faire soi-même ce type d'instruction. Il y en a d'autres : le PeekA()/PokeA() par exemple. Mais c'est celle qui me semble la plus performante, car les décalages sont pré-calculés par le CPU.
Le PDF c'est juste une description du protocole TCP/IP, on la trouve un peu partout (ex: wiki)
On voit que le checksum est codé sur 16 bits.
Dans mon cas, le protocole WebSocket, si la taille de la 'frame' dépasse 65536 octets, le checksum (Extended payload length) est codé sur 64 bits, soit 9,223,372,036,854,775,807 octets!
si la frame fait moins que ça (...) faut remplir le reste des 64 bits avec des zéros, si y'a au moins 8 zéros (ce qui arrive TRES souvent ) on a un caratère #NULL, et des problèmes à la lecture du buffer...
sa*op de serveur...
) on a un caratère #NULL, et des problèmes à la lecture du buffer... 