Salutations Willou62,

concernant la conversion vers le framework 1.1, il y a justement PWM63 (qui a posté quelques commentaires juste au dessus) qui m'a annoncé avoir effectué cette conversion en messagerie privée... je n'ai toutefois plus eu de nouvelles et je ne sais pas si sa conversion fonctionne à 100%, mais c'est une des meilleurs pistes que je puisse te proposer pour le moment, à part bien sûr de migrer directement sous Visual Studio 2005 (un bonheur... franchement, il faut y aller ! VS2003 se fait vraiment vieux).

Très cordialement,
Celiphane

Salut à ceux qui passent,

je n'ai eu de nouvelles des éventuels testeurs de ma source depuis la mise à jour...
Pourrais-je avoir un feedback et une note correspondante svp, j'ai besoin de retours pour estimer le travail et pouvoir le modifier en conséquence !

Cordialement,
Celiphane

Bonjour, suite à une question en messagerie privés, je fais partager à tous ma réponse, qui illustre 3 utilisations possibles :

___________________________________
Communications de Poste A à Poste B
___________________________________

But } Faire de la comm' d'un poste à un autre

- Instancier sur A une ClassComm avec un port en écoute
- lorsque la connexion est souhaitée, instancier sur B une ClassComm en passant l'IP du poste A, et le port choisi
- ClassComm A renvoit l'évènement << ConnectionRequestAccepted >>
- A n'a plus besoin d'écouter, donc on appelle la méthode << Dispose >> de ClassComm A et on la réinstancie en lui passant << Sck >>, le socket donné en argument

= Ici ClassComm A et ClassComm B peuvent communiquer
= Pour fermer l'une des deux, il faut lui faire appeler << Dispose >>, et l'autre renverra une erreur d'origine << seems_disconnected >>



________________________________
Communications ClientS / Serveur
________________________________

But } Par exemple une base de données nourrie à distance par des applis clientes

- une appli SRV instancie une ClassComm avec un port en écoute
- le client qui veut se connecter instancie sa ClassComm en passant l'ip du SRV et le port choisi
- ClassComm SRV lève l'event << ConnectionRequestAccepted >>
- il instancie une nouvelle ClassAPPLI (exemple) qui héberge une ClassComm en public
- la ClassAPPLI nouvellement créée instancie sa ClassComm avec << Sck >> qui a été fourni par l'event de SRV
- la ClassAPPLI est ajoutée dans une collection afin de continuer à vivre
- chaque ClassAPPLI gère donc ainsi sa communication avec une appli Cliente distante, dans notre exemple elle peut recevoir des requêtes SQL et les exécuter sur la base de données.

= Ici il peut donc y avoir des centaines de clients distants connectés sur une appli SRV



________________________________________________________
Communications Multi-clients, avec un serveur qui relaye
________________________________________________________

But } Des applis clientes qui passent par un serveur qui centralise les demandes pour les dispatcher aux autres applis clients

- exactement la même construction qu'en Clients / Serveur (ci-dessus)
- la collection d'appli clients sur SRV est public
- quand une appli cliente reçoit un message, il lui suffit de parcourir la collection pour faire demander à chaque ClassComm hébergée de faire passer un message.
- c'est au développeur de gérer ce qu'il faut faire (relayer ou non, à tous, à une appli cliente en particulier etc... la ClassComm se prête très bien à ce type de construction grâce à la réception séparée d'un ordre et d'un message : l'ordre renseigne sur ce qu'il faut faire du message)

= On peut tout faire en faite... enfin personnellement le DVP réseau m'a toujours ouvert l'esprit sur les possiblités infinies des applications, mais là avec cette ClassComm (et je me vante pas), c'est vraiment servi sur un plateau. Il ne reste plus qu'à y ajouter vos compétences, votre imagination et votre savoir-faire, car bien évidement, ce n'est qu'une class réseau, pas un wizard universelle !!! ;-)


Celiphane

Nouvelle mise à jour appliquée.
Voir dans l'historique des MAJ pour plus d'informations.

Celiphane

Message croisé, je reprends la parole rapidement pour rebondir sur ton dernier message : << car celle ci ne servirait donc plus qu'a communiquer entre un client ET un serveur codés à partir de ta classe >>.

Je suis désolé pour toi que tu ne l'ai pas compris plus tôt, mais c'est déjà le cas : ma classcomm ne communique qu'avec une autre classcomm.

ClassComm <----> ClassComm = oui
ClassComm <----> Socket = non

Elle ne peut servir en l'état qu'à simplifier la communication réseau dans une solution logicielle complète, mais ne peut pas s'intégrer dans une solution avec un protocle existant (genre navigateur web <----> ClassComm). Elle n'a pas pour but de simplifier l'utilisation des Sockets, elle EST à elle seule une forme de communication hyper simplifiée (à l'utilisation) qui REPOSE sur les sockets.

Cordialement,
Celiphane

Il n'y a pas à être désolé, j'estime que l'espace commentaires d'une source est fait pour ça !

Non rassure toi tu as parfaitement compris la question. Et tu as raison également sur le fait que dans l'absolu, c'est plutôt à l'utilisateur de transformer ses messages comme il l'entend.

Maintenant si on se place dans l'optique du développement d'une class parfaite et simple, si elle intégrait un cryptage et/ou une compression de données automatique et transparente pour l'utilisateur et ce sur simple demande dans le constructeur de la-dite class, ce serait un plus non négligeable voilà tout. Mais comme je l'ai dit plus haut, je n'en ai pas eu le besoin. Et comme j'ai initialement développé cela pour un projet bien conci, ça n'y figure pas voilà tout.  ;-)

Cordialement,
Celiphane

Et merci pour ton intérêt.

Salut CAOLILA,

J'y ai bien pensé mais je ne l'ai pas intégré, car je n'en ai pas le besoin. J'avais aussi pensé à la compression des messages.

Dans les deux cas, il suffit de rajouter la routine qui transforme le message (compression ou cryptage) dans la structure CommMessage au niveau de
<< Public ReadOnly Property MyBytes() As Byte() >> pour la transformation
et de
<< Public Sub SetBytes(ByRef ByteCommMessage As Byte()) >> pour le retour au message d'origine.

Je commence à travailler sur << mon bug de longueur >> expliqué dans le commentaire plus haut.

Cordialement,
Celiphane

Tout à fait, excellente remarque.
Annoncer l'arrivée de données via un évènement n'engage effectivement à rien d'autre que prévenir, et c'est en effet dans l'intérêt de l'utilisateur de la class.

J'intégrerais cet évènement en plus dans ma prochaine mise à jour que je compte finir après les fêtes de Pâques, car j'ai fait un oubli majeur sur cette class : les messages très longs sont actuellement scindé par le protcole TCP/IP (en paquet de 8192) et à la réception, la class pense que le message est complet alors qu'il ne l'est pas ! Bref quand elle tente de lire les bytes reçus alors qu'il s'agit d'un long message (ça se passe dans la sub << SetBytes >> de ma structure CommMessage), ça retourne une exception puisque le tableau de bytes est incomplet (a été scindé par le protocole TCP/IP).

Je n'avais pas réalisé dans mes petits tests de développeur genre << Coucou >> ou encore << Le chat boit du lait >> qu'en application réelle, on serait amené à envoyer des chaînes de plus 40Ko parfois lol ;-) !!!

Bref la solution est simple et je suis en train de la développer, c'est ma class qui va scinder les paquets pour reconstruire correctement à l'arrivé, et n'enqueuer QUE si la totalité des paquets sont parvenus. L'accusé de réception continuera de se faire paquet par paquet, et ça sera entièrement géré en interne.

Pardon pour cette erreur de parcours, quand j'y pense c'est si con de ma part de l'avoir oublié !

Celiphane

Salut l'ami,
je suis désolé pour toi d'avoir posté cette source avant la tienne !

Est-ce que c'est le fait de renvoyer le socket fraichement connecté à un serveur dans un event pour pouvoir le passer au constructeur d'une nouvelle class (pour << transformer >> le socket en ClassComm) que tu appelles une ruse ? Car je ne dirais pas que j'ai employé une quelconque feinte dans ce code source. Tu m'expliqueras quand tu pourras ! :-)

Concernant la gestion d'évènement, c'est effectivement un choix. Comme je l'ai expliqué, je n'ai pas souhaité obligé l'utilisateur de la class à devoir se synchroniser avec son interface à chaque réception de données. Voilà pourquoi j'ai opté pour une queue FIFO, ce qui permet en outre à l'utilisateur de traiter les messages dans l'ordre, de prendre tout le temps qu'il faut avec un message et de passer au second ensuite. A l'inverse en mettant les réceptions en évènement, le risque (et c'est fréquent) est que pendant la gestion d'un message fraichement reçu, un autre message arrive et redéclenche l'évenement ce qui fait que tout se déroule en même temps, je trouve que c'est confu et selon les cas ça peut faire des conflits (si les traitements des deux messages manipulent ne serait-ce qu'une même variable ou bien un même contrôle, les résultats deviennent inattendu).

Bref c'est pour ça que j'ai garder le concept du FIFO : les messages s'enqueuent les uns à la suite des autres, et même pendant qu'un message est en cours de traitement, la classcomm continu d'enqueuer les nouveaux messages, qui seront donc traités seulement à la suite, un par un, sans conflit ni résultat inattendu.

Je ne critique absolument pas, au contraire j'ai hâte devoir comment d'autres que moi gère tout ces inévitables conflits réseaux. Je présente juste ma vision des choses, avec mon expérience.

A très bientôt,
Celiphane