[.NETV2] CLASSCOM - CLASSE DE COMMUNICATION EN RÉSEAU SIMPLIFIÉE GÉRANT LE MULTI
celiphane
Messages postés
466
Date d'inscription
samedi 16 février 2002
Statut
Membre
Dernière intervention
20 avril 2007
-
6 avril 2007 à 14:56
Bobdesbois Messages postés 11 Date d'inscription mercredi 4 juin 2003 Statut Membre Dernière intervention 10 octobre 2008 - 10 oct. 2008 à 14:28
Bobdesbois Messages postés 11 Date d'inscription mercredi 4 juin 2003 Statut Membre Dernière intervention 10 octobre 2008 - 10 oct. 2008 à 14:28
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/42106-netv2-classcom-classe-de-communication-en-reseau-simplifiee-gerant-le-multiclient-2-en-1-client-et-serveur-class-socket
https://codes-sources.commentcamarche.net/source/42106-netv2-classcom-classe-de-communication-en-reseau-simplifiee-gerant-le-multiclient-2-en-1-client-et-serveur-class-socket
10 oct. 2008 à 14:28
Merci pour cette class. Je voulais savoir ce qu'il faudrai modifier pour l'utiliser sur windows mobile 5. Parce que j'ai essayé mais ca ne marche pas directement.
En tout cas elle marche tres bien pour du PC a PC.
Encore merci.
18 avril 2008 à 16:01
Cette classe m'est très utile, comme je l'ai déjà dit, mais je commence à atteindre ses limites : serait il possible d'inclure l'envoi de fichier ?(donc d'un tableau de byte directement plutôt qu'une string)
J'ai cherché longtemps comment faire, et la seule façon que j'ai trouvée est de transformer un fichier en string : System.Text.Encoding.Default.GetString(IO.File.ReadAllBytes(cheminDuFichier))
Cette méthode fonctionne mais je pense que ce serait bien plus rapide d'envoyer directement le fichier (j'ai essayé de modifier la classe, mais étant donné que j'ai déjà du mal à comprendre comment elle fonctionne...)
Alors Celiphane, si tu repasse par là, et que tu a du temps libre, je pense que ce serait une bonne idée...^^
Merci d'avance si quelqu'un répond
11 févr. 2008 à 14:37
Private Sub Srv_ConnectionRequestAccepted(ByRef SocketLocal As Socket) Handles Srv.ConnectionRequestAccepted
Try
'Création du thread
Dim myNewThread As New Thread(AddressOf Me.test)
' Dim myNewThread As New System.Threading.Thread(AddressOf test)
myNewThread.Name = "Thread ID:" & ThreadID
ThreadID += 1
'Invoke(New testDeleg(AddressOf test), New Object() {socket})
'Démarrage du Thread
myNewThread.Start(SocketLocal)
Catch ex As Exception
Console.WriteLine(ex.Message)
End Try
End Sub
11 févr. 2008 à 10:27
Je suis à la recherche d'une facon pour créer des threads afin de créer un nouveau client, chaque fois que le serveur recoit une demande de connection.
'ici le serveur reçoit la demande de connexion et l'accepte en créant le client ClassComm SrvReceive
Private Sub Srv_ConnectionRequestAccepted(ByRef sck As System.Net.Sockets.Socket) Handles Srv.ConnectionRequestAccepted
SrvReceive = New ClassComm(sck)
While SrvReceive.MsgCount < 1
End While
Dim cm As ClassComm.CommMessage = SrvReceive.ReadNextMsg
MySQL_SELECT(cm.Message)
End Sub
Comment faire pour créer un thread avec seulement ceci
SrvReceive = New ClassComm(sck)
While SrvReceive.MsgCount < 1
End While
Dim cm As ClassComm.CommMessage = SrvReceive.ReadNextMsg
MySQL_SELECT(cm.Message)
? Merci d'avance
1 févr. 2008 à 10:16
Bien structuré, lisible, commentaires et explications détaillées.
Merci.
24 nov. 2007 à 14:32
23 nov. 2007 à 15:26
19 juin 2007 à 20:54
Friend WithEvents Srv As New ClassCom(11000) 'ici en écoute sur le port 11000
Friend SDList As New ArrayList() ' Liste des sockets entrants
Friend SDSock As New ArrayList() ' Liste des IP des sockets entrants
'ici le serveur reçoit la demande de connexion et l'accepte en créant le client dans la liste associée des sockets
Private Sub Srv_ConnectionRequestAccepted(ByRef sck As System.Net.Sockets.Socket) Handles Srv.ConnectionRequestAccepted
Dim AcceptSock As New ClassCom(sck)
Dim WR As New StreamWriter("D:\xxx\Cnx.log", True) 'Fichier log
If SDList.Count > 9 Then 'Si l'on veut limiter le nombre de connexions
WR.Write(Now.ToString & " : Client -> connexion rejetée de " & sck.RemoteEndPoint.ToString & vbNewLine)
WR.Close()
WR.Dispose()
AcceptSock.Dispose()
Else
SDList.Add(AcceptSock)
SDSock.Add(sck.RemoteEndPoint.ToString)
AddHandler AcceptSock.ProblemDetected, AddressOf SD_ProblemDetected
WR.Write(Now.ToString & " : Client -> connexion de " & sck.RemoteEndPoint.ToString & vbNewLine)
WR.Close()
WR.Dispose()
AcceptSock.Send("Login", "Log")
End If
End Sub
Ensuite pour les supprimer de la liste suite à une déconnection j'ai modifié une ligne de la classe, à savoir
Public Event ProblemDetected(ByVal source As ErrorType, ByVal Cliente As Socket)
Puis dans ton programme...
Private Sub SD_ProblemDetected(ByVal source As ClassCom.ErrorType, ByVal Cliente As Socket)
Dim AcceptSock As New ClassCom(Cliente)
Dim WR As New StreamWriter("D:\xxx\Cnx.log", True)
For i as Integer = 0 To SDSock.Count - 1
If SDSock(i) = Cliente.RemoteEndPoint.ToString Then
WR.Write(Now.ToString & " : Client-> deconnexion de " & SDSock(i).ToString & vbNewLine)
AcceptSock.Dispose()
SDList.RemoveAt(i)
SDSock.RemoveAt(i)
End If
Next
WR.Close()
WR.Dispose()
end sub
18 juin 2007 à 07:46
13 juin 2007 à 22:06
ta classe est super cool il tombe à pic pour moi car je suis un projet de gestion de cybercafé , mais le problême est que comment puis-je identifier chaque client qui se connecte et pouvoir luis répondre chaque fois qu'il emet une demande ou lorsque le serveur à un message propre à un client specifique je cfais comment?
merci d'avant pour ta réponse
13 mai 2007 à 00:43
12 mai 2007 à 20:55
25 avril 2007 à 13:39
Bonne continuation et surtout bonne prog!
25 avril 2007 à 11:37
Par contre, elle ne fonctionne pas à 100%, et je n'ai toujours pas pris le temps de me pencher dessus pour résoudre un problème mineur.
Stéphane.
20 avril 2007 à 23:42
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
20 avril 2007 à 21:26
. L'idée de cette class est vraiment excellente et félicitation pour cette prog.
20 avril 2007 à 09:42
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
12 avril 2007 à 13:42
___________________________________
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
11 avril 2007 à 15:51
Voir dans l'historique des MAJ pour plus d'informations.
Celiphane
11 avril 2007 à 10:18
En tout cas, j'attends avec impatience la mise à jour pour le bug de longueur.
Félicitations !
Stéphane
10 avril 2007 à 17:50
Grosse erreur de ma part, je n'avais donc pas totalement saisi le but de ta classe, je m'excuse et reviens sur ma remarque: oui il serait donc très interessant d'ajouter cryptage et compression directement à celle-ci :)
Caolila : cf le message pour celiphane, betise de ma part, à oublier :)
bonne continuation à vous deux
10 avril 2007 à 17:32
Le but de cette classe n'est il pas de rentre la vie plus facile a l'utilisateur finale ?
C'est dans ce contexte et uniquement dans celui-ci que je parlais de "securite" de de "sniffage". Si tu prends le FTP ou le POP3 tout est en clair et donc il est tres tres facile de lire un mot de passe. apres boujour les dégats.
Imagine le travail dans un team, chacun a sa specialité (pour ne pas dire ses problemes) et si ce genre d'integration (securité, compression etc) est transparente c'est le pied et un gain de productivité..
N'oublions pas que les clients (les gars qui payent mon salaire) sont soucieux de leur sécurité...donc autant l'integrer en standard...
Hugues
10 avril 2007 à 17:28
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
10 avril 2007 à 17:25
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
10 avril 2007 à 17:21
10 avril 2007 à 17:19
Si la solution que vous sous-entendiez était le cryptage, je pense fortement que c'est à l'utilisateur de la classe de gerer ça et non le contraire
peut-être que je n'ai rien compris à la remarque, et dans ce cas je m'en excuse et veut en savoir plus :D
(désolé celiphane de prendre de la place sur ton espace ^^)
10 avril 2007 à 17:12
10 avril 2007 à 17:11
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
10 avril 2007 à 15:57
As tu pensé a la question de la sécurité, les ptits paquets peuvent etre "sniffer" et la... tout est possible pour un gars sachant un tout petit peu bidouiller....
10 avril 2007 à 15:54
Sympa ta source j'vais voir ca de plus pres, moi aussi je bosse sur un truc similaire afin de gerer une application Client Serveur avec des clients du genre "chiant", cad de Clients WCE avec WLAN, ce sont des scanners de codebare. Avec des engins pareils il n'est pas rare pour ne pas dire tres tres regulier que la connection soit perdu pour des raisons diverses (perte de réseau, reset utilisateur etc...).Le serveur doit garder trace de tout puisqu il s'identifie a une DB au nom du Client WCE (User + Pass)
Dans la version actuelle j'ai choisi la meme solution que Celiphane, cad de faire une file d'attente ainsi qu'un AR. Il est en effet tres important de pouvoir traiter les paquets dans l ordre afin d'eviter les bugs du genre update avant create...hehehe
bref je vous ferais un ptit coucou apres avoir regarde ce post en détail.
Sinon a priori bon boulot .
@+
Hugues
8 avril 2007 à 19:16
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
8 avril 2007 à 14:57
oui, moi j'ai consideré cela comme une ruse, car j'ai mis pas mal de temps à trouver un moyen d'en arriver là. D'ailleurs, ce n'est pas exactement la même methode, moi je fais ça dans un constructeur privé (est ce dans les normes? :/), à partir de la classe elle même et je n'ai d'ailleurs pas préciser que j'ai fait deux classes distinctes client et serveur. (alors qu'a l'origine je voulais refaire Winsock de vb6, mais j'ai trouvé ça plus pratique... et plus lisible)
Enfin bref, JE JE JE, on verra quand j'aurais posté, parlons de ton projet:
Il faut avouer que ton petit speach sur la méthode FIFO m'a plus ou moins convaincu et je commence à me demander si je ne devrais pas ajouter la possibilité de passer par autre chose que des évenements, même si mes nombreux tests ont pourtant été satisfaisant depuis la synchronisation(zut j'en reviens à moi).
Mais par contre, de ton coté, cela pourrait tout de même être pratique de renvoyer un envénement, sans données en arguments, mais pour prévenir qu'un "message" est arrivé. Apres celui ci, tu utilise la même méthode que lorsque c'est ton timer qui voit qu'un nouveau msg est là. Cela reste dans ton idée, non?
7 avril 2007 à 22:45
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
7 avril 2007 à 20:45
Par contre perso j'ai opté pour une gestion d'évenement, avec la possibilité d'effectuer une synchronisation entre les threads. Je posterais d'ici quelques jours le resultat ici (d'ou ma deception quand j'ai vu ton post ^^)
7 avril 2007 à 16:29
Pour répondre à ta question, cette class peut s'utiliser à chaque fois que tu auras besoin de faire un application qui fonctionnera en réseau. Les usages sont donc multiples, du plus simple chat / dialogue en direct, jusqu'à la plus complexe des applications clients / serveur en entreprise par exemple.
Chaque fois que tu auras besoin de faire des applications qui devront communiquer en réseau, poste à poste ou bien architecture clients / serveur, tu peux sortir cette class de ta manche et elle t'épargnera un fastidieux codage de sockets, mais aussi le développement d'un protocole de communication perso ainsi que des tests de bonnes réceptions de tes messages réseaux. Elle gère tout cela.
Instancié en serveur, la class est dès le début orienté multiclients pour l'architecture clients / serveur. Si on ne souhaite pas faire du multiclients mais juste du poste à poste, à l'évènement ConnectionRequestAccepted de la classcomm serveur il suffit de lui faire << .Dispose >> puis de la réinstancier en passant à son constructeur le socket fourni par l'évènement. Et voilà, c'est devenu un simple poste à poste.
Je pense que tous ceux qui ont déjà l'habitude de coder en réseau appréciront ces fonctionnalités très simples.
Cordialement,
Celiphane
7 avril 2007 à 14:14
ta source a l'air vachement bien faite, bien expliquée, je vais la tester un peu pour voir... mais avant, dans quel cas devrais-je utiliser ta classe? dans quand quel type d'application?
merci d'avance.
6 avril 2007 à 14:56
Cordialement,
Celiphane