AUTOSOCKET, UN CLONE DU CONTRÔLE WINSOCK EN .NET
cs_mahhoura
Messages postés
15
Date d'inscription
vendredi 23 janvier 2004
Statut
Membre
Dernière intervention
25 août 2007
-
5 févr. 2004 à 10:10
Xya Messages postés 103 Date d'inscription lundi 8 juillet 2002 Statut Membre Dernière intervention 24 novembre 2005 - 2 sept. 2009 à 21:50
Xya Messages postés 103 Date d'inscription lundi 8 juillet 2002 Statut Membre Dernière intervention 24 novembre 2005 - 2 sept. 2009 à 21:50
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/20110-autosocket-un-clone-du-controle-winsock-en-net
https://codes-sources.commentcamarche.net/source/20110-autosocket-un-clone-du-controle-winsock-en-net
2 sept. 2009 à 21:50
2 sept. 2009 à 21:40
31 août 2009 à 14:34
Merci! Et c'est marrant parce qu'en ce moment je suis aussi en train de bosser avec des sockets, mais non bloquants (sous Linux) et avec Python.
Pour être honnête ça fait des années que j'ai pas touché au code et que j'ai pas programmé en VB.NET donc je suis pas sûr d'être d'une grande aide pour trouver le bug.
Mais pour essayer, est ce que les données sont bien envoyées? Est ce que si tu mets un point d'arrêt sur '_socket.Send(data, ...)' dans AutoSocket.Send() il passe dessus? Et sur la ligne 'RaiseEvent DataDeparture' ?
31 août 2009 à 11:38
Premièrement, je tiens à dire que ce code est vraiment super !
Ensuite, j'ai un petit problème avec les évènements DataDeparture et SendComplete. L'évènement ne se déclenche pas.
J'ai cherché dans le code de la classe d'où pourrait venir l'erreur, mais sans succès.
Voila, voila...
Merci d'avance.
Kardyne.
21 juil. 2009 à 12:42
Comment mettre dans une variable les données d'un socket precis ?
merci
29 avril 2009 à 18:28
Donc d'un côté c'est moins pratique, mais ça force à bien réfléchir à l'architecture de l'application, le flux de données, les threads, etc. Perso c'est quelque chose que j'adore et que je trouve hyper intéressant, mais ça demande pas mal de temps et de recherches.
Par exemple c'est pas une bonne chose d'appeler des fonctions blocantes (synchrones) sur le thread de l'interface graphique, puisque ça fait freezer l'affichage de tes fenêtres. C'est pour ça que le plus simple c'est d'avoir un thread dédié à ton socket. L'alternative c'est d'utiliser les fonctions asynchrones ou des événements mais c'est plus difficile à bien structurer, enfin c'est mon point de vue.
29 avril 2009 à 15:21
Bref je m'y suis mi et je ne le regrette pas, mais je regrette for mon Mswinsck.ocx... ce bon vieux winsock était si facile d'utilisation...
Je trouve franchement la classe system.Net.Socket très mal faite, j'ai même trouvé des exemple de code socket avec des fonctions non synchrones et des timers !
En ce qui concerne ton code il sera toujours utile jusqu'à modification par MS de System.Net.Socket...
29 avril 2009 à 14:57
Ce qui m'étonne un peu c'est que ce bout de code soit toujours utile et utilisé, même 5 ans après que je l'ai écrit !
A+
Xya
29 avril 2009 à 14:36
Merci bien pour toutes ces informations heureusement qu'il y a encore des gens pour partager leur savoir et filer un coup de main sans attendre des choses en retour :) (ce qui fait que le développement évolu plus vite que certaine personnes ou choses de la vie...)
Merci encore @+
29 avril 2009 à 14:27
Par exemple imaginons que tu crées le socket dans le constructeur de ta form:
Public Sub New()
'...
Me.socket = New AutoSocket()
Me.socket.SynchronizingObject = Me
End Sub
et après dans tes gestionnaires d'événements t'as plus à te soucier de Invoke/BeginInvoke (cad les événements sont automatiquement exécutŽs dans le thread principal):
Private sub Control_Disconnect (sender as Object, e as System.EventArgs) Handles Control.Disconnect
'Je veu par exemple afficher "déconnecté" dans un label
label.Text = "Déconnecté"
End sub
29 avril 2009 à 13:18
Car si on gère le code normalement au niveau du formulaire on n'a qu'a faire :
Private sub Control_Disconnect (sender as Object, e as System.EventArgs) Handles Control.Disconnect
'Je veu par exemple afficher "déconnecté" dans un label
If (Label.InvokeRequired) Then
Label.Invoke(New DelegSub(AddressOf e_Connexion), Sender, e)
Else
Label.Text = "Déconnecté"
End If
End sub
Et la on obtient l'état de l'objet de synchronisation du label, mais dans le cas ou le code est géré par ma classe comment transmettre ce paramètre à "syncObj" ???
29 avril 2009 à 12:57
Je vais tester ca de suite, encore Merci ;)
29 avril 2009 à 12:44
Protected syncObj As ISynchronizeInvoke 'objet de synchronisation Windows Forms
Public Property SynchronizingObject() As ISynchronizeInvoke
Get
Return syncObj
End Get
Set(ByVal Value As ISynchronizeInvoke)
syncObj = Value
End Set
End Property
Pour chaque événment tu dois ajouter une méthode OnXXX qui détermine si on doit utiliser BeginInvoke ou pas:
Public Event Disconnected(ByVal sender As Object, ByVal e As EventArgs)
Protected Overridable Sub OnDisconnected(ByVal e As EventArgs)
If Not syncObj Is Nothing AndAlso syncObj.InvokeRequired Then
Dim deleg As New EventHandler(AddressOf SyncDisconnected)
syncObj.BeginInvoke(deleg, New Object() {Me, e})
Else
SyncDisconnected(sender, e)
End If
End Sub
Et une øéthode SyncXXX qui déclenche juste l'événement:
Protected Sub SyncDisconnected(ByVal sender As Object, ByVal e As EventArgs)
RaiseEvent Disconnected(sender, e)
End Sub
La version VB.NET est un peu lourde, comme je pense pas qu'on puisse récupérer le délégué de l'événement contrairement à C#, sinon on pourrait faire (dans OnXXX):
syncObj.BeginInvoke(Me._delegue_Disconnected, New Object() {Me, e})
et se passer de SyncXXX.
Pas de soucis :p J'espère que ca te øettra sur la voie.
29 avril 2009 à 11:48
Je suis en train de faire une classe de dialogue TCP avec un protocole intégré et des fonctions qui utilise les sockets.
Cette classe permettra entre autre de gérer les connexions Client/serveur, l'envoi de message simplifié avec paramètres et gèrera directement l'envoi de fichier avec événements (Start, Finish, Progress...).
J'aimerais pourvoir faire des événements (un peut comme dans ta classe), en ce qui concerne les sockets sans avoir à chaque fois à appeler BeginInvoke/Invoke... :/
J'ai recherché partout mais j'ai pas trouvé grand chose, de plus je ne suis pas un expert en ce qui concerne le multithreading.
ET Merci pour ta disponibilité :p
29 avril 2009 à 08:29
29 avril 2009 à 08:20
J'ai pu trouver quelques explications en faisant des recherches hier,
Par contre... c'est bizard car quand je démarre le programme compilé ça fonctionne ?
l'exception n'est pas prise en compte ???
29 avril 2009 à 00:24
Le problème, c'est que tout les contrôle windows forms (namespace System.Windows.Forms.*) doivent être impérativement utilisés sur le thread principal (c'est à dire tout code qui accède à leur méthodes et propriétés). Il n'y avait aucune vérification dans le Framework 1.1, par contre je crois que c'est à partir du 2.0 que cette "règle est vérifiée", et si elle n'est pas respectée, tu obtiens l'exception que tu as copié-collé.
La solution la plus rapide, c'est d'appeller BeginInvoke/Invoke dans tous les événements du socket, de sorte à exécuter le code qui accède à Windows Forms dans le thread principal. Exemple:
Private Sub socket_DataArrival( sender As Object, data As Byte() )
Me.BeginInvoke(ma_fonction_windows_forms, New Object[] {data}) ' synatxe VB?
End Sub
Private Sub ma_fonction_windows_forms(data As Byte())
txtClientInput.Text = Encoding.UTF8.GetString(data)
End Sub
Ca fait des années que j'ai pas fait de VB.NET (et pas de compilateur sous la main), donc je me souviens plus de la syntaxe, surtout pour la création de tableau et le passage du délégué (voir commentaire).
L'idée c'est tu passe un délégué de ta fonction (ici ma_fonction_windows_forms) comme 1er paramètre, et un tableau contenant la liste des paramètres de ta fonction comme 2ième paramètre. Ca c'est la solution rapide, bête et méchante, et pas hyper propre.
La solution plus "clean" serait de rajouter une propriété SynchronizingObject (de type ISrynchronizeInvoke -- interface implémentée par tous les contrôles Windows Forms) à la classe de Socket. Ensuite tu dois utiliser la méthode BeginInvoke de ton objet SynchronizingObject pour déclencher les événements.
Je pense qu'avec ça tu dois avoir pas mal de pistes pour régler le problème (je pense que tu devrais trouver sur le net le code pour utiliser BeginInvoke/Invoke et les événements VB.NET). J'espère que ça t'aidera!
Greetings from Norway
Xya
28 avril 2009 à 23:18
Opération inter-threads non valide : le contrôle 'txtClientInput' a fait l'objet
d'un accès à partir d'un thread autre
que celui sur lequel il a été créé.
Suis-je le seul à qui cette erreur est survenue ?
26 févr. 2008 à 17:28
Merci
8 sept. 2007 à 23:28
Merci bcp sa va me débloquer dans un de mes projets !!
8 sept. 2007 à 14:23
C'est un Source tré tré util
merci pour la Class !
Je souaite développer un Serveur SMTP, IMAP et POP3
S'a peux M'aider ?
Merci de Me Contacter par Email ou Directe...
11 juil. 2006 à 19:09
Dans tous les cas TCP ou UDP, tu l'instancie la socket avec cette commande :
_socket = New Socket(af, SocketType.Stream, prot)
SocketType.Stream pour de l'UDP -> plantage
Mais sinon vraiment tres pratique comme appli, bravo ;)
16 mars 2006 à 08:14
Je vous explique mon problème. Je souhaite faire un peer2peer privé. Donc arriver à joindre directement une personne sur internet via son ip pour lu itransmettre des paquets. jusque la, rien de bien difficile. Si bien sur les 2 clients sont les passerelles internet.
Supposons maintenant un reseau X1 ou il y a les ordinateur A1, B1 et C1 et A1 est la passerelle.
Supposons aussi un reseau X2 ou il y a les ordinateur A2, B2 et C2 et A2 est la passerelle.
Comment faire pour que C2 puisse directement communiquer avec C (ou B1) sans faire de serveur sur A1 ou A2.
Car mon application marche que de passerelle à passerelle. J'ai essayé le multicast par desespoir mais celà ne apsse pas dans Internet.
Si vous pouviez m'aiguiller dans mon problème par un bout de code .... j'en serai plus que ravi !
Bernard
19 févr. 2006 à 23:42
Redman
1 févr. 2006 à 17:09
Merci d'avance
Salutations
17 janv. 2006 à 08:21
Aurais-tu une idée ?
Merci encore ...
16 janv. 2006 à 09:36
par contre j'ai du placer cette boucle dans la boucle suivante. Sinon l'erreur se produisait encore de temps en temps.
Merci pour ton aide précieuse !
13 janv. 2006 à 12:51
13 janv. 2006 à 12:49
Voilà le code à rajouter dans AutoSocket.Send:
Dim bytesLeft As Integer = data.Length
Dim sendTotalBytes As Integer = data.Length
Dim sendCurrentBytes As Integer = 0
'<==== Code à rajouter
'attend que le socket soit prêt, il se peut que le buffer d'envoi
'soit plein, ce qui lève une exception puisque le socket n'est pas bloquant
While !Socket.Poll(0, SelectMode.Write)
System.Threading.Thread.Sleep(0)
End While
' Code à rajouter ====>
While bytesLeft > 0
12 janv. 2006 à 12:12
Ce code m'a permis de faire un bon dans l'avancement de mon projet. Par contre, l'erreur suivante se produit de temps en temps lorsque j'appelle la méthode Send de ta classe AutoSocket :
"System.InvalidOperationException : Impossible de bloquer un appel sur ce socket, pendant qu'un appel asynchrone antérieur est en cours."
Pour le moment mon application n'envoie qu'une seule trame, mais en reçois plusieurs.
Mes connaissances dans les Socket étant limitées pour l'instant, j'aimerais que tu m'aides à ce sujet.
Merci pour ton aide !
2 janv. 2006 à 13:03
Je suis depuis peu sous VB 2005 et le framework 2. J'essaie en vain, de réaliser un composant similaire en utilisant les classes suivnates : TcpListener, TcpClient et BackGroundWorker.
Malheureusement, mes compétences dans le domaines des sockets (TcpListener, TcpClient étant des dérivées) sont limitées et font que je n'y arrive pas. (Héhé on peut tout savoir faire non plus.)
Ton code est très bien fait, et devrait m'en apprendre beaucoup.
Il faut continuer !!!
14 oct. 2005 à 21:35
Cela me servira beaucoup ! Merci !
Bonne continuation !
25 avril 2005 à 18:22
je comprend pas trop pourquoi, puisque c'est lui le serveur, mais bon.
25 avril 2005 à 18:20
ks.Connect(New IPEndPoint(IPAddress.Parse(addresse), Int32.Parse(port)))
je fais ça pour me connecter dont addresse = 127.0.0.1 ou mon IP
mais dès que je tombe sur _socket.Connect(remoteEP) là ça plante avec un "Aucune connexion n'a pu être établie car l'ordinateur cible l'a expressément refusée"
pourtant mon serveur est bien sur Nom: localhost et port est bien le même.
j'ai fermé tout les firewall et antivirus, donc c'est pas ça non plus
je fais les tests sur un même ordi
8 avril 2005 à 09:11
Je vais commencer par me documenter sur les événements parceque je ne connais pas vb.net; juste vba pour l'instant donc forcèment je suis hyper limité sur le coté "événementiel" de la chose :/
7 avril 2005 à 19:15
Pour connecter plusieurs clients, voilà où modifier le code:
dans AutoSocket.vb, dans la région "Evénéments"
Private Sub eventSink_Accept(ByVal sender As Object, ByVal status As Integer) Handles eventSink.Accept
Dim newSocket As Socket = Socket.Accept()
If closeServer Then
_socket.Close()
Else
_baseServer = CloneSocket()
End If
_socket = newSocket
'crée un nouveau dispatcheur: le handle du socket a changé
ResetEventSink(_socket.Handle)
_state = SocketState.Connected
RaiseEvent Connected(Me, EventArgs.Empty)
End Sub
Je pense qu'il faudrait ajouter un événement ClientConnected à AutoSocket avec comme paramètre le nouveau socket qui est connecté au client à la place de l'événement Connected.
Dans eventSink_Accept, le serveur ne fermerait pas le socket sur lequel il écoute, créerait un nouveau AutoSocket avec le Socket retourné par Accept - donc ajouter un constructeur Private qui prend comme paramètre un Socket et qui initialiserait ce socket (voir NewSocket) - ne réinitialiserait pas le dispatcheur d'événement (ResetEventSink), laisserait l'état du socket sur SocketState.Listening et lancerait l'événement ClientConnected.
Voilà, j'espère que ça pourra t'aider sur ton projet.
7 avril 2005 à 10:48
Ca m'aide pas mal pour mon projet.
Par contre je cherche un moyen de connecter plusieurs clients.
Comment puis-je modifier le code pour celà ?
Merci
23 janv. 2005 à 14:27
22 janv. 2005 à 21:11
21 déc. 2004 à 13:57
En effet il manque le serveur multithread, comme je n'ai jamais fait de serveur multithread :)
En fait j'ai fait cette source pour les programmes "de bureau", qui ne tournent pas sur un serveur, genre client mail, client FTP, chat, envoi de fichiers ...
21 déc. 2004 à 10:02
26 juil. 2004 à 11:02
Tres bonne source, Pour moi qui suit un grand debutant, cela me fait progresser.
Comme deja demander, comment faire pour que le serveur accepte, plusieur connection.
Et comment faire pour que le serveur continue d'ecouter quand le client se deconnecte.
Un grand merci, pour ton tarvail, continue a nous envoyer de bonne source.
19 juil. 2004 à 19:44
J'ai ajouté le controle à mon projet, je me connecte à un serveur irc, lorsque le me "whois" sur celui ci, je suis bien connecté.
Lorsque je tente d'utiliser la méthode "Send", il me renvoit une erreur signalant que je suis déconnecté.
J'ai mit un point d'arrêt sur Sock_Closed, mais le programme ne s'arrête jamais sur ce point.
Que faire ?
17 juil. 2004 à 16:48
10 mai 2004 à 16:17
Merci Xya, là comme ca c'est un génial remplaçant de Winsock pour .net !
Je vais tester chez moi (je suis au bureau là) en modifiant un peu le prg pour voir si on sait facilement envoyer des fichiers et voir si progression OK.
10 mai 2004 à 13:15
Enjoy!
Xya
9 mai 2004 à 23:32
Mais j'ai 2 questions ;
- System.net.socket remplace bien winsock de VB6 ? pq ils ont pas prévu les évènements (indispensables) de Winsock alors ? ou faut-il pour ca utiliser une autre classe ?
- tu n'as pas fait l'évènement SendProgress disponible dans WinSock. C'est facile à ajouter ?
21 avril 2004 à 17:47
Après tu peux facilement acceder à ta liste avec un navigateur.
http://[ip ou nom de l'ordi]:[port ouvert par le serveur web]/[page web à générer]
Par exemple:
http://dionysos:80/listprocess.html
http://dionysos:80/lkillprocess.html?pid=123
J'espère que ça peut t'aider.
Xya
21 avril 2004 à 15:13
Saurais tu egalement svp comment je pourrais fair pour envoyer des information sur une ecoute de socket apartire d'un page web et avoir un retour
Par exemple sur une page web avoir le listing des processus en route sur mon ordi et d'envoyer l'ordre de fermer tel ou tel processus.
merci
21 avril 2004 à 06:24
Type: bibliothèque de classes
Espace de noms racine: System.Net.Sockets
Objet de démarrage: aucun
Option Explicit On
Option Strict Off
et tu ajoutes à ce projet les fichiers sources .vb présents dans le zip.
Ca devrait marcher.
Xya
20 avril 2004 à 15:00
si tu a une idée a me propose merci de m'en faire part msn dionysos6868@hotmail.com
merci de ton aide
20 avril 2004 à 14:32
merci
13 avril 2004 à 14:00
cependant ca serait interssant de permettre plrs con vers serveur(comme suggéré par cognicasse),ds ce cas soit il faut résoudre le prob des index(groupe de control en vb6),soit utiliser des thread(chaque requéte entrante sera un nouvel thread) sinon creer des instances(à chaque reéception coté serveur) d'un objet socket(par exemple).je travaille actuellement la dessus.
sinon,bon courage et merçi
26 mars 2004 à 02:11
Un petit ajout serait de permettre plusieurs connection sur le serveur avec un nom d'usager comme le fait MSN pis ca y est tu aurais refait MSN .... avec .net ...
8 mars 2004 à 21:59
Xya
8 mars 2004 à 16:48
8 mars 2004 à 16:09
Ca tombe bien, le post qu'il me fallait MAIS...j'arrive pas a trouver le namespace de la classe autosocket...surtout que je trouve null part un sti renseignement sur cette classe...
Merci pour toutes infos sup !
29 févr. 2004 à 20:13
Sinon si tu décompile le code du Framework tu vois qu'un grand nombre de classes sont juste des wrappers qui utilisent massivement les appels à l'API de Windows (Socket, FileStream, System.Windows.Forms, System.Threading, System.Security.Cryptography, Microsoft.Win32 (là c'est normal :p), GDI+, etc), mais je suis d'accord avec toi qu'il faut plutot écrire du code portable, par exemple pour pouvoir être exécuté sur Mono.
Sinon pour la classe AutoSocket j'ai réussi à un peu l'améliorer, à savoir se débarasser du thread qui dispatche les événements, en utilisant les événements de Windows (les classes Auto/Manual-ResetEvent) et RegisterWaitForSingleObject de ThreadPool: en fait, j'avais pas remarqué que les events WinSock étaient des bêtes events de Windows :)
Faut que je mette à jour le zip.
Xya
29 févr. 2004 à 01:55
Comme c'est dit dans la Classe d'ailleurs :) "Unsafe"
Je pense qu'une autre version du Composant pourrait se contenter de ce qu'offre le Framework en standard et offrir des interfaces plus sympa pour la gestion du stream.
Sinon c bien :)
5 févr. 2004 à 13:33
Xya
5 févr. 2004 à 10:10