Je profite d’un ptit créneau que j’ai sous windows pour essayer de tester un peu le C#.
Je me dis “cool jvais utiliser les surcouches qui facilitent la vie au monde pour faire un client IRC”.
Je regarde un peu … ok un tcpclient ça a l’air bien, j’envoie ok.
Par contre, ce que je n’arrive pas à faire c’est lui dire que quand quelque chose arrive sur le socket il doit me le dire.
J’ai pris un bouquin à la BU sur le C#, dans lequel ça parle d’evenement notament pour un exemple d’une classe maison “button” avec un event sur un click.
Et donc quand ils instancient le boutton il y a un truc du genre leboutton.Click += leEventHandler …
Sauf que dans mon cas j’ai PAS vu de tcpclient.quelquechosearrive …
Pour info, je “veux” utiliser un truc tres simple, si c’est pour y aller avec des socket, read, connect et companie c’est pas la peine.
Quelqu’un pour m’illuminer ?
Merci et Bon appétit B)
(si j’ai de la chance les g33ks du boulots seront sur la zone à l’heure du déjeuner B))
(quoi qu’au boulot c’est plus midi la pause déjeuner :s)
Ben heu c’est normal, Tcp assume rien sur le protocole que tu utilise et TCP etant construit sur IP, les donnees arrivent par paquets, qui sont bufferises par le hardware et par l’OS, donc il est impossible de faire un evennement “data arrive” qui ait un sens. Tu construit une grammaire pour ton protocole, et tant que t’as pas quelque chose qui ait un sens a ce niveau la tu veux continuer a lire, puis balancer un event la a la limite, ca te servirait a quoi DataReceived a ce niveau la? A rien de plus que de faire un read asynchrone ou meme bloquant. Sans compter que ca implique une gestion multi thread qui impose tellement de trucs que ca a absoluement rien a voir dans ce genre de classe a ce niveau et qui comme le protocole depend de l’application. Utiliser des events comme unique methode de signalisation cross thread… c’est se preparer de l’arrachage de cheveux. Ca sert pas a ca un event, un event, c’est une liste chainee de delegates, qui sont appelles dans l’ordre et qui permettent de faire le pattern publisher/subscriber c’est tout. Enfin au niveau architecture d’appli ca serait une cata. Chai pas si je suis clair et je m’en excuse si c’est pas le cas B)
Si tu veux vraiment faire un truc du genre a ce niveau la, ce que je recommende absoluement pas, c’est pas impossible a implementer tu fais un read asynchrone par exemple, tu bloques sur un ManualResetEvent ou un truc du genre (la c’est le bon type d’event, hehe) que tu signalles quand des data arrivent et qui balance l’evenement avec ses handlers. M’enfin c’est vraiment pas un modele de programmation qui pour moi a un sens a ce niveau la.
Merci à vous.
En fait, soit jme goure, soit la seule façon de faire ce que je veux c’est effectivement un listen asynchrone qui s’ocucpe de ce qu’il reçoit.
Sinon, je vois pas B)
Ok, comment que je fais alors pour savoir quand quelque chose arrive (ie quand je dois afficher le texte des gens qui parlent ou arrivent) pour que ça soit tout beau ?
Personnelement, même si j’ai tres peu de connaissances sur les sockets et ce genre de chose, il faut pas oublier le principe de l’architecture client/serveur.
Tu as un serveur qui attends les requêtes du client. A toi de voir pour construire un mode de fonctionnement la dessus.
Ca semble pas extrêmement complexe pour créer le principe de base ( envoi d’un message au serveur, et reception des nouveaux messages par les clients )
En fait ce qui me “gene” c’est que c’est mal de toujours “écouter” pour savoir si quelque chose arrive et que rien ne permet de dire “attention voilà un truc qui peut etre potentiellement du contenu à afficher”, donc je dis que je vois pas comment faire.
(et là c’est moi qui commence à me demander si je suis clair)
Ah toi aussi ? Il doit aussi me rester un début de client MSN pas plus fini que ca, un client FTP et un client de newsgroup. Moi commencer des trucs c’est ma passion. Les finir, c’est une autre histoire par contre.
Je crois que t’approche pas le probleme comme il faut a ce niveau la. Il te faut (enfin il faut… on peut…) construire une couche “protocole” qui va etre celle qui “ecoute tout le temps” et recoit des messages. Un packet IP sur une connection TCP (ou quelques bytes sur un stream vu que c’est ce que tu as au niveau TcpClient) ne consitue pas un message. Tu dois lire assez de donnees pour reconstituer un message, savoir quel type de message il s’agit, et ensuite eventuellement “lever” des evenemments qui correspondent au message en question. Par exemple, j’imagine sur IRC “ReceivedIrcServerMessage”, ou un truc comme ca. Tu as surement tout un tas d’autre messages qui ont rien a voir avec ca. La grammaire du protocole est la bas: http://www.irchelp.org/irchelp/rfc/chapter2.html#c2_3
Bon je crois que je vais aller me coucher, editer tout ça demain car plus j’en lis et plus je me dis que j’ai vraiment pas du être clair …
Merci pour la grammaire, ça m’évitera de retrouver ma session en netcat B)
Le noyau IRC est open-source, c’est un fork du SmartIRC4Net de mon copain meebey avec des choses pas RFC du tout mais en accord avec les réalités d’IRC de nos jours.
La version sur le site est hyper outdatée, je sais, ma version de dev est juste 10 000x plus puissante (avec les plugins (SSL, Blowfish), une interface plus rapide et plein de trucs sucrés), je bosse doucement (les etudes, la copine, ça prend du temps) dessus et j’ai jamais le temps de faire des releases.
J’ai acheté le domaine en debut d’année, j’ai meme pas été fichu de faire un site correct.
Vu qu’un switchage sur Mac est de plus en plus a l’etude (birthday 20 ans powaa), j’en suis meme a me demander si je vais pas tout recoder en C++ avec Qt4.