Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

loginQueueStatusMessage

Moufett

Bonjour,

Aujourd'hui j'ai finalement réussi a envoyer le paquet 4 ("identificationMessage") et recevoir une réponse correct du serveur. Le problème est que je reçois un paquet introuvable dans les sources de D. (sauf dans les messages) . Je sais donc comment récupérer l'information contenu dedans; mais je ne sais pas comment le client réagis face a ce paquet(car il n'est pas dans les frames).

Le paquet en question est "loginQueueStatusMessage" .

La connexion est également interrompue quand j'essaie de recevoir un second paquet.

EDIT : Il se trouve que la connexion lâche car je reçois le paquet num "loginQueueStatusMessage" en boucle, donc je suppose que je dois arrêter de recevoir le paquet pendant un moment ; la question est combien de temps ?

Donc si quelqu'un sait ou se trouve le "switch" qui gère les paquet de Queues ce serait gentil ;)

Merci d'avance.

BlueDream

On ne doit apriori rien faire avec ce paquet c'est juste a titre d'information. Tu dois avoir un probleme autre si le serveur te déco. Montre nous tes logs

Moufett

Mes logs ne sont malheureusement pas très développées, mais en gros ça fais ça :

réception ProtocolRequired :: id 1

réception helloConnectMEssage :: id 3

Envoie identificationMessage :: id 4

réception loginQueueStatusMessage :: id 10

etc ...

Puis :

Socket se ferme avec l'erreur 10053 (qui je pense est du au fait que j'envoie trop de requêtes au serveur )

Merci d'avance

BlueDream

Je ne sais pas du tout, tu reste constamment bloqué sur ce paquet ?

Moufett

Il se trouve que oui, peut-être est-ce dû à ma structure socket particulière ? Je n'utilise pas de boucle d'écoute mais je profite plutôt du fais que recv() est bloquante , chose que beaucoup de personnes ne font pas.

Je peux également montrer mon code si cela aide ?

merci

BlueDream

Rajoute moi sur Skype:

alexandre.frydman

j'aimerais bien voir le tout, je posterais la solution sur cadernis.

Sparkdaemon

Socket se ferme avec l'erreur 10053

go check du côté du MSDN http://msdn.microsoft.com/en-us/library/windows/desktop/ms740668%28v=vs.85%29.aspx

BlueDream

Le problème vient de la gestion des paquet, Moufet va ramettre sa en place.

ToOnS

Moufett a dit : "Il se trouve que oui, peut-être est-ce dû à ma structure socket particulière ? Je n'utilise pas de boucle d'écoute mais je profite plutôt du fais que recv() est bloquante , chose que beaucoup de personnes ne font pas.
Je peux également montrer mon code si cela aide ?
merci"

c'est pourca que beaucoup de personnes le font pas :mrgreen: ou le font mais dans un thread , ca evite justement les time-out

Moufett

Oui en effet, ma manière de recevoir les paquets n'était pas au point ^^

Je vais travailler sur ce détaille cette semaine .

Je vous remercie tous pour votre soutient et a bientôt ! :)

Moufett

Bonjour ,

J'ai finalement fini par me créer une structure de réception tip top !

Mais je remarque que le problème ne s'est pas résolu pour autant.

Il semblerai que la connexion soit interrompue juste après la réception du paquet "loginQueueStatusMessage" . Quelqu'un a t'il déjà eu ce problème ?

BlueDream

Bonsoir,

la je ne sais plus quoi dire. Normalement le problème vient du RSA, si je ne me trompe pas, le rsa est vérifié apres le loginqueuestatutmessage. Si il ne te dise rien quand tu envoi le 3 c'est que le nombre de données, le count de ton credential est bon mais je pense effectivement que tout est réellement verifie apres le queue. Normalement tu aurais du recevoir un paquet bad credential a moins que ton rsa ne ressemble vraiment a rien et la dofus te déco direct.

Moufett

Bonjour,

tout est clair maintenant . Je pensais que le crédential était vérifié avant le paquet 10.

Merci pour tout

BlueDream

Moufett a dit : "Bonjour,
tout est clair maintenant . Je pensais que le crédential était vérifié avant le paquet 10.
Merci pour tout"

Il vérifie juste si ton credential 'a l'air' correct. Nombre de count, boolean etc.

Le vrai vérification a lieu plus tard :-)