2016-10-05 4 views
1

J'utilise TcpListener (Clase) exemple https://msdn.microsoft.com/es-es/library/system.net.sockets.tcplistener(v=vs.110).aspx afin de traiter les demandes TCP.Comment faire pour distribuer des demandes de TCP Listener

Mais il semble que dans le même temps ce TCP Listener va accepter plusieurs demandes qui devraient être traitées plus tard dans un couple de Web Services ensemble et le résultat doit être retourné au TCP client.

Je pense faire ce qui suit:

  1. obtenir un objet de flux pour la lecture et l'écriture NetworkStream stream = client.GetStream(); et enregistrez-le dans la classe de conteneur spécial.

  2. Mettez cette classe à la classe auxiliaire spéciale Queue comme celle-ci C#: Triggering an Event when an object is added to a Queue.

  3. Lorsque Queue est modifié, l'événement implémenté par le feu est traité pour traiter l'élément de file d'attente suivant de manière asynchrone à l'aide de Task.

  4. Dans un Task communiquer avec Web Services et envoyer la réponse à TCP Client.

S'il vous plaît, laissez-moi savoir cette architecture est vitale et capable de résoudre les multiples demandes de TCP Listener.

+2

Et pourquoi les mettre en file d'attente? Ensuite, toutes les demandes suivantes attendront que toutes les précédentes soient terminées. – Evk

+0

@Evk Eh bien ... Je ne suis pas sûr de la file d'attente et je pense que j'ai besoin d'un type de BUFFER pour garder 'NetworkStream stream = client.GetStream();' rapidement ... Pensez-vous qu'il suffit de créer 'Task' et garder toute la logique là-bas? –

+1

Eh bien, cela dépend de la charge, je pense. Dans certains cas, je pense que la file d'attente est une bonne solution, surtout dans les cas où ce que vous faites avec chaque élément est lié au CPU (quelques calculs lourds). Mais ici, les choses sont liées à l'E/S (vous faites des requêtes web), vous devriez donc pouvoir gérer beaucoup d'entre elles sans file d'attente. Donc, si la charge sur ce service ne sera pas très élevée - je pense que oui, le traitement des choses en parallèle (avec des tâches régulières) devrait être bien. – Evk

Répondre

1

L'utilisation de la file d'attente est une idée tout à fait viable, mais réfléchissez à son but. Cela limite le nombre de requêtes que vous pouvez traiter en parallèle. Vous devrez peut-être limiter cela dans plusieurs cas, et le plus souvent est que chaque traitement de requête effectue un travail lié au processeur (calculs lourds). Votre capacité à traiter un grand nombre d'entre eux en parallèle est donc limitée et vous pouvez utiliser l'approche par file d'attente.

Dans votre demande, le traitement effectue un travail lié à l'E/S (attente de la demande Web à compléter). Cela ne consomme pas beaucoup de ressources serveur, et vous pouvez traiter beaucoup de ces demandes en parallèle, donc très probablement dans votre cas, aucune file d'attente n'est nécessaire.

Même si vous utilisez une file d'attente, il est très rarement utile de traiter un seul élément à la fois. Au lieu de cela, traiter la file d'attente avec des threads X (où X dépend à nouveau si le travail est lié à l'UC ou à l'E/S, pour CPU, X = nombre de cœurs, avec IO vous avez besoin de plus). Si vous utilisez trop peu de threads pour traiter votre file d'attente - vos clients attendront plus pour rien, et peuvent même échouer en expirant.