C/C++ Poco ou Boost.asio

[noilir]

Bonjour,
Je suis en train de développer un émulateur ("juste" la partie échange réseau pour l'instant).
J'ai trouve quelques sources d'émulateur en c++ sur github et j'ai remarqué que la plupart sont développés avec Poco.
Pour ma part, je viens de l'émulation de wow et je suis "habitué" (c'est relatif) à Boost.asio.
Qu'en pensez-vous? Poco::Net ou Boost.asio? Quel choix faites vous et pourquoi?
http://pocoproject.org/
http://www.boost.org/doc/libs/1_58_0/doc/html/boost_asio.html
A bientot!
PS: j'ai un niveau très moyen en c++, il se peut donc que des subtilités m'aient échappées entre ces deux bibliothèques, n'hésitez pas à m'en faire part!

 

[Labo]

Pour être honnête, je ne connaissais pas du tout Poco. Poco a l'air d'être de plus haut niveau, ce qui rend le développement plus rapide et simple, mais ne permet pas la même flexibilité.
http://stackoverflow.com/questions/16120142/is-boostasio-equivalent-to-poconet

 

[noilir]

Effectivement, avec Poco::Net j'ai très rapidement eu un serveur qui recevait les sockets tcp, mais ne gérant pas bien l’écriture et la réception asynchrone.
Je m'inspire donc de l’implémentation des émulateurs wow sous Boost.asio pour développer mon serveur. C'est plus long mais j'apprends plus et le résultat est plus sur.


EDIT: pas sur que je reste sur Boost.asio, je continue mes tests!

 

[Harkhann]

Sinon il y a aussi SFML qui est pas mal. Elle est beaucoup plus simple que Asio mais suffisante à mon goût pour un bot dofus(je n'en suis qu'au début). Elle a aussi l'avantage de gérer les threads, fenêtres, sons et a quelques petits bonus sympa comme la classe Packet ou encore le fait d'être multi-plateforme.
http://www.sfml-dev.org/index-fr.php

 

[noilir]

Bonsoir Harkham,
Je connais bien SFML, je l'ai beaucoup utilisé pour son module graphique, je trouve cependant que son module réseau est trop limité.
De plus Laurent Gomilla (le créateur de la SFML) précise qu'il est préférable d'utiliser les threads du standard (std::thread) que ceux de SFML.
En tout cas pour l'instant je suis reparti sur mon serveur Poco, je verrai ce qu'il en est lorsque j'aurai fini le serveur de connexion.

 

[Harkhann]

Moi elle me suffit, mais je vais peut être jeter un coup d'oeil à Poco si ça vaut vraiment le coup de changer.

 

[Sorrow]

J'ai déjà utilisé les deux que tu propose, boost ya pas mal de temps, super en particulier l'async mais horrible de lire du code boost, des namespace et callback de partout, pas évident de coder par intention.

Poco je l'est utilise récemment, super simple et intuitif, mais dans un soucis de faire quelques chose de super léger et "hight capacity" je me suis tourné vers libevent, donc je suis justement en train de retirer cette dépendance.

Les deux ce valent, je te conseil de lire cet article : http://www.codeofhonor.com/blog/choosin ... etwork-lib

 

[noilir]

Bonsoir Sorrow!
En effet j'ai vu les sources de ton core "cawotte"
Du coup je reste avec Poco pour l'instant et je verrai plus tard si ça tient la route ou pas,
quitte à changer, ce n'est qu'une couche réseau :roll:

 

[Sorrow]

Bon code
(Si tu regarde mes sources, regarde la branche "server", la master n'est pas à jour)

 

[noilir]

Bonsoir!
Merci^^
Je vais regarder alors si tu le permets j'ai beaucoup de mal avec le RSA.
J'ai une interrogation la...
Si dofus envoie les paquets en big-endian...Et que le serveur tourne sur une machine little-endian. Ca va pas faire des etincelles?

 

[BlueDream]

Il suffit de reverse l'ordre des data ou bien d'utiliser mes IO :mrgreen:

"De la même manière que certains langages humains s'écrivent de gauche à droite, et d'autres s'écrivent de droite à gauche, il existe une alternative majeure à l'organisation des octets représentant une donnée : l'orientation big-endian et l'orientation little-endian."

https://fr.wikipedia.org/wiki/Endianness

 

[noilir]

Ok je voulais confirmation
Bon je vais aller dormir car mon ému plante méchamment après l'envoi du paquet 3 :evil:
EDIT: en fait pour HelloConnectMessage, moi je génère un salt de 32 caractères et je prend la clef publique dans le fichier 381.bin à laquelle j'ai enlevé les bornes ---PUBLIC KEY---- etc... Ca devrait etre bon non?

 

[BlueDream]

Ah non pas du tout, la clé publique est celle qui permet le décryptage et non le cryptage qui dépend d'une clé privé absolument secrète et aléatoire :geek:

 

[noilir]

Ok alors du coup j'ai sniffer le HelloConnectMessage officiel et je me retrouve avec un fichier binaire qui contient uniquement la clef et qui pese 310 octets. Qu'en penses tu? je vais tester mais je pense que c'est trop lourd non?

 

[BlueDream]

La clé envoyé par le serveur via le HelloConnectMessage contient 305 éléments et le salt fait une taille de 32.

 

[Sorrow]

Faut récupérer une clé valide envoyer par Ankama pour ton ému, sa évite à avoir à patcher le client avec une nouvelle clé, ya plus simple.
Tu envoi la clé officiel, le client te répond avec les credentials (chiffré), tu envoi un RawDataMessage qui contient un SWF qui récupère est identifiants et les envoi en claire (ou md5, ou ce que tu veux) dans un nouveau message.

On avait créer un spécialement pour ça : ClearIdentificationMessage, id 888
Puis une fois les IDs vérifier tu répond avec IdentificationMessage(Success|Failed).

 

[noilir]

Ok merci encore pour vos réponses, j'ai vérifié, la clef que je reçois fait 305 octets donc ca doit etre bon, je la teste des que je peux!
Sorrow ton histoire de paquet m’étonne, tu ne peux pas déchiffrer les credentials?

 

[BlueDream]

Eh bien non logiquement on ne peut pas sans la clé privé qui est contenu dans le serveur.
De plus le RawDataMessage contient une signature, tu dois utiliser une ancienne version du client.

 

[noilir]

Sinon je modifie le client et je supprime l'updater, comme ça je met en place mon propre RSA?
Ce serait possible ça?

 

[BlueDream]

Les modifications sont très complexes, la moindre erreur et ton swf est à refaire. De plus tu risques de devoir travailler en ppcode.

Ce que tu peux faire c'est modifier la clé publique contenue en binaire dans le client.