WaitForSingleObject en C# (ou comment recevoir à la fois FD_READ, FD_AC CEPT, et un event quelconque)
3 réponses
herbert
bonjour à tous,
j'avais fait en c++ deux classes; serveur et client
le serveur créait un thread qui attendait pour des messages
d'acceptation de la part de la socket de listenning, et des messages de
lecture pour les sockets acceptée, plus un event d'arrêt du thread,
lorsque le destructeur de la classe était appelé.
J'ai du mal à faire la même chose en c#, vu qu'il n'y a pas de destructeur.
D'autre part, je ne peut pas arrêter le Socket.Select ou le Socket.Pool
à part si je met une durée, si je teste une valeur, ce qui ne me parait
pas du tout optimisé, si je veux faire un serveur d'un milier de client.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Paul Bacelar
A votre place, j'utiliserais Reflector (http://www.aisto.com/roeder/dotnet) pour avoir le code de Socket.Select qui je modifierais pour attendre votre objectif.
Socket.Select est un mince wrapper au-dessus du select de WinSock2, cela permettra d'avoir un appel P/Invoke pratiquement tout fait. -- Paul Bacelar
"herbert" wrote in message news:
bonjour à tous,
j'avais fait en c++ deux classes; serveur et client
le serveur créait un thread qui attendait pour des messages d'acceptation de la part de la socket de listenning, et des messages de lecture pour les sockets acceptée, plus un event d'arrêt du thread, lorsque le destructeur de la classe était appelé.
J'ai du mal à faire la même chose en c#, vu qu'il n'y a pas de
destructeur.
D'autre part, je ne peut pas arrêter le Socket.Select ou le Socket.Pool à part si je met une durée, si je teste une valeur, ce qui ne me parait pas du tout optimisé, si je veux faire un serveur d'un milier de client.
Quel est la bonne approche ?
A votre place, j'utiliserais Reflector (http://www.aisto.com/roeder/dotnet)
pour avoir le code de Socket.Select qui je modifierais pour attendre votre
objectif.
Socket.Select est un mince wrapper au-dessus du select de WinSock2, cela
permettra d'avoir un appel P/Invoke pratiquement tout fait.
--
Paul Bacelar
"herbert" <herbert.vongrunenwald@microsoft.com> wrote in message
news:edBDq4DCFHA.4028@TK2MSFTNGP15.phx.gbl...
bonjour à tous,
j'avais fait en c++ deux classes; serveur et client
le serveur créait un thread qui attendait pour des messages
d'acceptation de la part de la socket de listenning, et des messages de
lecture pour les sockets acceptée, plus un event d'arrêt du thread,
lorsque le destructeur de la classe était appelé.
J'ai du mal à faire la même chose en c#, vu qu'il n'y a pas de
destructeur.
D'autre part, je ne peut pas arrêter le Socket.Select ou le Socket.Pool
à part si je met une durée, si je teste une valeur, ce qui ne me parait
pas du tout optimisé, si je veux faire un serveur d'un milier de client.
A votre place, j'utiliserais Reflector (http://www.aisto.com/roeder/dotnet) pour avoir le code de Socket.Select qui je modifierais pour attendre votre objectif.
Socket.Select est un mince wrapper au-dessus du select de WinSock2, cela permettra d'avoir un appel P/Invoke pratiquement tout fait. -- Paul Bacelar
"herbert" wrote in message news:
bonjour à tous,
j'avais fait en c++ deux classes; serveur et client
le serveur créait un thread qui attendait pour des messages d'acceptation de la part de la socket de listenning, et des messages de lecture pour les sockets acceptée, plus un event d'arrêt du thread, lorsque le destructeur de la classe était appelé.
J'ai du mal à faire la même chose en c#, vu qu'il n'y a pas de
destructeur.
D'autre part, je ne peut pas arrêter le Socket.Select ou le Socket.Pool à part si je met une durée, si je teste une valeur, ce qui ne me parait pas du tout optimisé, si je veux faire un serveur d'un milier de client.
Quel est la bonne approche ?
herbert
Paul Bacelar wrote:
A votre place, j'utiliserais Reflector (http://www.aisto.com/roeder/dotnet) pour avoir le code de Socket.Select qui je modifierais pour attendre votre objectif.
Socket.Select est un mince wrapper au-dessus du select de WinSock2, cela permettra d'avoir un appel P/Invoke pratiquement tout fait.
Merci pour l'info ! Ceci m'amène une autre question: je pense qu'il est possible, comme pour java, d'obfusquer les sources dans un executable. Ceci est-il possible dans Visual c# .NET ?
Sinon, pour arrêter mes threads, il suffit de faire thread.Abort(), dans Dispose de l'interface IDisposable. (même s'il est dans une fonction bloquante de socket)
merci
Paul Bacelar wrote:
A votre place, j'utiliserais Reflector (http://www.aisto.com/roeder/dotnet)
pour avoir le code de Socket.Select qui je modifierais pour attendre votre
objectif.
Socket.Select est un mince wrapper au-dessus du select de WinSock2, cela
permettra d'avoir un appel P/Invoke pratiquement tout fait.
Merci pour l'info !
Ceci m'amène une autre question: je pense qu'il est possible, comme pour
java, d'obfusquer les sources dans un executable. Ceci est-il possible
dans Visual c# .NET ?
Sinon, pour arrêter mes threads, il suffit de faire thread.Abort(), dans
Dispose de l'interface IDisposable.
(même s'il est dans une fonction bloquante de socket)
A votre place, j'utiliserais Reflector (http://www.aisto.com/roeder/dotnet) pour avoir le code de Socket.Select qui je modifierais pour attendre votre objectif.
Socket.Select est un mince wrapper au-dessus du select de WinSock2, cela permettra d'avoir un appel P/Invoke pratiquement tout fait.
Merci pour l'info ! Ceci m'amène une autre question: je pense qu'il est possible, comme pour java, d'obfusquer les sources dans un executable. Ceci est-il possible dans Visual c# .NET ?
Sinon, pour arrêter mes threads, il suffit de faire thread.Abort(), dans Dispose de l'interface IDisposable. (même s'il est dans une fonction bloquante de socket)
merci
Paul Bacelar
"herbert" wrote in message news:
Paul Bacelar wrote: > A votre place, j'utiliserais Reflector
(http://www.aisto.com/roeder/dotnet)
> pour avoir le code de Socket.Select qui je modifierais pour attendre
votre
> objectif. > > Socket.Select est un mince wrapper au-dessus du select de WinSock2, cela > permettra d'avoir un appel P/Invoke pratiquement tout fait.
Merci pour l'info ! Ceci m'amène une autre question: je pense qu'il est possible, comme pour java, d'obfusquer les sources dans un executable. Ceci est-il possible dans Visual c# .NET ?
Sinon, pour arrêter mes threads, il suffit de faire thread.Abort(), dans Dispose de l'interface IDisposable. (même s'il est dans une fonction bloquante de socket)
"herbert" <herbert.vongrunenwald@microsoft.com> wrote in message
news:4200A152.7050702@microsoft.com...
Paul Bacelar wrote:
> A votre place, j'utiliserais Reflector
(http://www.aisto.com/roeder/dotnet)
> pour avoir le code de Socket.Select qui je modifierais pour attendre
votre
> objectif.
>
> Socket.Select est un mince wrapper au-dessus du select de WinSock2, cela
> permettra d'avoir un appel P/Invoke pratiquement tout fait.
Merci pour l'info !
Ceci m'amène une autre question: je pense qu'il est possible, comme pour
java, d'obfusquer les sources dans un executable. Ceci est-il possible
dans Visual c# .NET ?
Sinon, pour arrêter mes threads, il suffit de faire thread.Abort(), dans
Dispose de l'interface IDisposable.
(même s'il est dans une fonction bloquante de socket)
Paul Bacelar wrote: > A votre place, j'utiliserais Reflector
(http://www.aisto.com/roeder/dotnet)
> pour avoir le code de Socket.Select qui je modifierais pour attendre
votre
> objectif. > > Socket.Select est un mince wrapper au-dessus du select de WinSock2, cela > permettra d'avoir un appel P/Invoke pratiquement tout fait.
Merci pour l'info ! Ceci m'amène une autre question: je pense qu'il est possible, comme pour java, d'obfusquer les sources dans un executable. Ceci est-il possible dans Visual c# .NET ?
Sinon, pour arrêter mes threads, il suffit de faire thread.Abort(), dans Dispose de l'interface IDisposable. (même s'il est dans une fonction bloquante de socket)