sebseb42
Messages postés495Date d'inscriptiondimanche 6 juillet 2003StatutMembreDernière intervention 9 novembre 2007
-
11 mars 2006 à 03:24
sebseb42
Messages postés495Date d'inscriptiondimanche 6 juillet 2003StatutMembreDernière intervention 9 novembre 2007
-
11 mars 2006 à 12:42
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
sebseb42
Messages postés495Date d'inscriptiondimanche 6 juillet 2003StatutMembreDernière intervention 9 novembre 20071 11 mars 2006 à 12:42
Pour répondre plus succintement à ta question, non ce n'est pas de l'asynchrone, car Accept est bloquante, mais oui, il est possible d'avoir plusieurs client.
Le code est disponible, a toi d'implémenter BeginAccept et EndAccept si tu veux, ca pourrait être pas mal :) C'est aussi ca l'idée d'un code ouvert, l'amérioration :)
Personnellement je n'utilise jamais Begin* et End* mais ca peux être bien de l'implémenter car il en faut pour tout le monde.
On pourrait même après mettre mon code dans la lib CS :P
sebseb42
Messages postés495Date d'inscriptiondimanche 6 juillet 2003StatutMembreDernière intervention 9 novembre 20071 11 mars 2006 à 12:39
Attention, je rappel que le SecureTcpListener n'est pas une classe qui gère un serveur a part entière, il ne gère pas lui même le pool de thread/sockets avec events et tout le tremblement, mais ceci dit, il est evidement possible d'avoir plusieurs client avec un seul SecureTcpListener, c'est a vous d'implementer la façon dont vous gérez vos thread/sockets.
La fonction Accept de SecureTcpListener est bloquante, quand elle se débloque, elle renvoie un SecureTcpClient qui a la faculté de pouvoir communiquer en crypter (ou non) avec un autre SecureTcpClient. Lorsque la fonction Accept se termine, le SecureTcpListener est evidement toujours actif et opérationnel. Il vous suffit d'effectuer le traitement adéquat sur votre SecureTcpClient (l'envoyer dans un thread par exemple) et ensuite de reboucler sur le Accept du SecureTcpListener, ce qui bloquera une fois de plus, et au débloquage vous renverra un nouveau SecureTcpClient, avec un clef de session differente (et evidement une pair de clef publique/clef privée est générée pour chaque client).
J'espère avoir répondu au mieux à ta question.
cs_wizad
Messages postés355Date d'inscriptionsamedi 30 octobre 2004StatutMembreDernière intervention14 avril 2009 11 mars 2006 à 12:01
Je n'ai pas encore tester mais le traitement asynchrone des connexion avec la possibilité d'avoir plusieur client est il possible?
sebseb42
Messages postés495Date d'inscriptiondimanche 6 juillet 2003StatutMembreDernière intervention 9 novembre 20071 11 mars 2006 à 03:24
Je précise, en gros pour le code c'est un Start et un Accept pour le serveur, un Connect pour le client, et ensuite tout les Send et Receive sont cryptés dans les deux sens, l'utilisateur (vous) n'a strictement rien a faire.
J'espère que cet code poura être utile à tous ceux qui se sont toujours demandé comment implementer ce genre de choses, bien souvent redouté par les débutant pour sont apparente complexité mais en faite ô combien simplifié par le Framework .NET 2.0
11 mars 2006 à 12:42
Le code est disponible, a toi d'implémenter BeginAccept et EndAccept si tu veux, ca pourrait être pas mal :) C'est aussi ca l'idée d'un code ouvert, l'amérioration :)
Personnellement je n'utilise jamais Begin* et End* mais ca peux être bien de l'implémenter car il en faut pour tout le monde.
On pourrait même après mettre mon code dans la lib CS :P
11 mars 2006 à 12:39
La fonction Accept de SecureTcpListener est bloquante, quand elle se débloque, elle renvoie un SecureTcpClient qui a la faculté de pouvoir communiquer en crypter (ou non) avec un autre SecureTcpClient. Lorsque la fonction Accept se termine, le SecureTcpListener est evidement toujours actif et opérationnel. Il vous suffit d'effectuer le traitement adéquat sur votre SecureTcpClient (l'envoyer dans un thread par exemple) et ensuite de reboucler sur le Accept du SecureTcpListener, ce qui bloquera une fois de plus, et au débloquage vous renverra un nouveau SecureTcpClient, avec un clef de session differente (et evidement une pair de clef publique/clef privée est générée pour chaque client).
J'espère avoir répondu au mieux à ta question.
11 mars 2006 à 12:01
11 mars 2006 à 03:24
J'espère que cet code poura être utile à tous ceux qui se sont toujours demandé comment implementer ce genre de choses, bien souvent redouté par les débutant pour sont apparente complexité mais en faite ô combien simplifié par le Framework .NET 2.0
Merci Bill :)