11 réponse par Savageman

  • Enregistré : 07 Apr. 2008
  • Posts info : 126

Re : Handshake Websocket

Alors tant que j'y suis j'ai peut-être autre chose. Qui est certes un cas limite mais c'est pas une bonne raison pour l'ignorer et il peut p'tet bien arriver quand même (d'ailleurs je suis tombé dessus d'où le fait que j'y pense).

Genre quand le socket est accepté, il est dans la liste des nodes. On peut donc lui envoyer un message. Sauf qu'il n'a pas encore forcément fait son handshake. Du coup patatrac : au premier message envoyé le client refuse la connexion car il n'a pas obtenu la bonne réponse au challenge.

Qu'en penses-tu ?

Sinon rien à voir mais j'ai regardé la denrière version de ton code et tu passes par des opcode. C'est uniquement une gestion interne ou bien c'est décrit quelque part dans le protocole Websocket ? Le OPCODE_CONTINUATION_FRAME permet d'envoyer plusieurs messages en un coup ? Un petit eclaircissement sur le pourquoi du comment serait pas mal. smile Merci tout plein !

12 réponse par Hywan

  • Hywan
  • Administrateur
  • Offline
  • De : Montécheroux
  • Enregistré : 06 Apr. 2008
  • Posts info : 1,659

Re : Handshake Websocket

Quand une socket est acceptée, elle a un nœud asssocié. Elle connaît aussi le serveur sur lequel elle tourne (plus exactement, qui l'a lancée) et donc peut obtenir la liste des autres nœuds (qui contient les instances des sockets et des serveurs et encore d'autres informations). Ça c'est Hoa\Socket\Server qui propose ça.

Par contre, là, on a une grosse différence entre Hybi-00 et Hybi-06+ il me semble. C'est que pour Hybi-00, le premier message va servir de handshake et donc finira à la poubelle. Alors que Hybi-06+ va envoyer les en-têtes tout seul, puis viendra le premier message (qui ne finira pas à la poubelle).
Le mieux est donc d'envoyer un message à la con la première fois (qui sera ignoré) histoire d'être sûr, un peu comme un ping. Je dois vraiment vérifier ça.

Je dois encore fixé ça car je n'ai pas fini mes tests à ce propos. Je sais que j'ai eu des soucis avec le chat à cause de ça. J'ai réglé le problème en truant un peu, mais bon … Après, c'est difficile à gérer pour le serveur, mais pas impossible !

Enfin, les OPCODE sont définis par la norme draft-ietf-hybi-thewebsocketprotocol-06 (et plus). Ce n'est pas mon imagination (pour une fois wink).
Les différents opcode sont expliqués dans ce draft (voir la section 4, Data Framing). Ils ne sont pas explicitement appelés comme ça mais leurs valeurs si. Il faudrait que tu regardes le schéma. Je ne l'ai pas remis dans le code par flemme (ce serait utile ? plus de doc et d'explication dans le code ou plus de lien vers le draft ?).
Le continuation frame permet de faire de la fragmentation (voir la section 4.4, Fragmentation. D'ailleurs, mon code n'est pas blindé (comme le protocole change, je préfère faire léger et fonctionnel puis je blinde à la fin). La fragmentation c'est le fait de pouvoir envoyer plusieurs frames pour un seul message : on scinde le message en plusieurs bouts. Comme avec le chunck-mode pour HTTP si on veut. C'est pratique pour de gros messages car les sockets sont nulles pour envoyer d'énormes messages. Donc on envoit le message petit bout par petit bout. Peut-être devrais-je envoyer un événement (genre on('message-fragment')) pour pouvoir commencer à faire des traitements même si le message n'a pas fini d'arrivé ?

« Un handicap est le résultat d'une rencontre entre une déficience ou différence et une incapacité de la société à répondre à celle-ci. »

Hywan Website