une instance de system.net.sockets.socket
peut être partagé par 2 threads afin d'utiliser la méthode Envoyer () et une autre méthode de réception ()?
est-ce sûr?
Eh bien, j'en ai besoin pour être non seulement de sécurité, mais également que les méthodes d'envoi / réception soient non syncronisées, de manière à laisser chaque fil les appeler simultanément.
Dois-je une autre façon de le faire?
Merci d'avoir aidé, je suis expérimenté à Java, mais j'ai eu du mal à essayer de faire celui-ci.
3 Réponses :
Il devrait être en sécurité, oui. La classe Socket est citée par MSDN pour être complètement sécurisé .
Je ne sais pas si c'est une bonne idée cependant. Vous pourriez vous rendre difficile pour vous-même en utilisant deux threads. Vous voulez probablement regarder Begsonend et beginReceive pour les versions asynchrones, auquel cas ne devriez pas avoir besoin de plusieurs threads.
Premièrement, je suis préoccupé non seulement sur la sécurité du fil, mais également l'utilisation simultanée de lecture / écriture. et hmm, ok, laissez-moi demander quelque chose de plus s'il vous plaît répondez-moi. Sous la hotte, l'utilisation de ces méthodes asynchrones gère un autre fil pour atteindre la rigidité de l'asincronique? Si oui, chaque fois que j'appelle commence ..., créera-t-il un nouveau fil?
Autant que je sache, un nouveau fil est créé, mais ce ne sera pas un nouveau fil pour chaque appel. J'ai fait un petit test pour confirmer, et ça ressemble vraiment à cette façon.
Je crois que les méthodes asynchronisées utilisent des threads threadpool plutôt que de créer un nouveau fil spécifique
@Matt: C'est vrai. Cela pourrait ou non créer un nouveau fil, en fonction de la disponibilité de fils inactifs dans la piscine de thread. La distinction n'est généralement pas pertinente, je l'ai donc laissé à l'origine. Quelques informations ici: MSDN.MicRosoft.com/en-us/Library/ms973903. ASPX
Oui, il est parfaitement sûr d'accéder à envoyer et à recevoir de deux threads différents en même temps.
Si vous souhaitez que votre application soit échelle à 100 des sockets actives, vous souhaiterez utiliser les méthodes de BeginReceiveve / Begningend plutôt que de créer des threads manuellement. Cela fera de la magie dans les coulisses afin que vous ne produisiez pas 100 de fils pour traiter les sockets. Ce que c'est exactement dépendant de la plate-forme. Sous Windows, vous utiliserez les ports d'achèvement des «hautes performances». Sous Linux (mono), vous utiliserez Epoll je crois. De toute façon, vous allez finir par utiliser beaucoup moins de threads que des prises actives, qui est toujours une bonne chose :)
Pourquoi dites-vous que l'utilisation d'un fil dédié pour recevoir / envoi imposera une latence de grève ou imposer un problème d'évolutivité que d'utiliser les méthodes asynchronisées?
Supposons que vous ayez 500 prises ouvertes et que vous ne recevez que d'eux. Vous auriez besoin de faire tourner 500 threads, chacun d'entre eux bloquant sur Socket.Receive (). Supposons maintenant que vous utilisiez la version asynchrone de la méthode. Le point d'exécution .NET va remettre les sockets au système d'exploitation et dire "Dis-moi quand ils ont des données". Lorsqu'ils ont des données, l'exécution prendra un fil de threadpool et invoquera l'asynccallback afin que vous puissiez traiter vos données. Ceci est un lot plus performant que le contexte basculant 500 threads.
Peu de sujet hors tension, mais utiliser des méthodes de synchronisation n'est utile que si vous avez des clients limités. J'ai compris que les sockets Async sont plus lentes avec la réponse. Les tremploits ASYNC sont beaucoup mieux avec la manipulation de nombreux clients.
Alors: Sync est bien plus rapide. ASYNC est plus évolutif