Как распространять запросы от прослушивателя TCP

Я использую TcpListener (Clase) пример https://msdn.microsoft.com/es-es/library/system.net.sockets.tcplistener(v=vs.110).aspx для обработки запросов TCP.Как распространять запросы от прослушивателя TCP

Но похоже, что в то же время это TCP Listener собирается принять несколько запросов, которые должны быть обработаны позже в пару Web Services вместе, и результат должен быть возвращен TCP client.

Я имею в виду, чтобы сделать следующее:

Получить объект потока для чтения и записи NetworkStream stream = client.GetStream(); и сохранить его в специальном классе контейнера.
Положить этот класс в специальный Queue вспомогательный класс как этот C#: Triggering an Event when an object is added to a Queue.
Когда Queue изменено событие, связанное с огнем, для асинхронного обработки следующего элемента очереди с использованием Task.
В пределах Task общаются с Web Services и отправляют ответ на TCP Client.

Пожалуйста, дайте мне знать, эта архитектура имеет жизненно важное значение и в состоянии решить многочисленные запросы TCP Listener.

источник

2016-10-05 Academy of Programmer

И зачем их ставить в очередь? Затем все последующие запросы будут ждать завершения всех предыдущих. – Evk

@Evk Ну ... я не уверен в очереди, и я думаю, что мне нужно, чтобы BUFFER поддерживал 'NetworkStream stream = client.GetStream();' быстро ... Как вы думаете, достаточно создать 'Task' и сохранить там всю логику? –

Ну, это зависит от нагрузки, которую я думаю. В некоторых случаях я думаю, что очередь - хорошее решение, особенно в тех случаях, когда то, что вы делаете с каждым элементом, связано с ЦП (некоторые тяжелые вычисления). Но здесь вещи привязаны к IO (вы делаете веб-запросы), поэтому вы должны иметь возможность обрабатывать многие из них без очереди. Так что если нагрузка на эту услугу будет не очень высокой - я думаю, да, обработка файлов параллельно (с обычными задачами) должна быть прекрасной. – Evk

Использование очереди - это определенно жизнеспособная идея, но подумайте, какую цель она служит. Он ограничивает количество запросов, которые вы можете обрабатывать параллельно. Возможно, вам придется ограничить это в нескольких случаях, и наиболее обычным является то, что каждая обработка запросов выполняет работу с привязкой к ЦП (тяжелые вычисления). Тогда ваша способность обрабатывать многие из них параллельно ограничена, и вы можете использовать подход к очереди.

В обработке запросов выполняется работа с привязкой к IO (ожидание завершения веб-запроса). Это не потребляет много ресурсов сервера, и вы можете обрабатывать множество таких запросов параллельно, поэтому, скорее всего, в вашем случае очередь не нужна.

Даже если вы используете очередь, очень редко обрабатывать только один элемент за раз. Вместо этого очередь процессов с потоками X (где X снова зависит от того, работает ли работа с процессором или IO, для CPU вам может быть хорошо, если X = количество ядер, с IO вам нужно больше). Если вы используете слишком мало потоков для обработки очереди - ваши клиенты будут ждать больше, в основном ничего, и могут даже терпеть неудачу с тайм-аутом.

источник

2016-10-05 13:58:37 Evk

Я бы порекомендовал вам netmq. Посмотрите https://github.com/zeromq/netmq

источник

2016-10-05 13:55:19

Как распространять запросы от прослушивателя TCP

ответ

Смежные вопросы