NetworkStream Pooling
У меня есть многопоточное приложение, которое связывается с сервером через TCP-соединение. Приложение будет развернуто как служба Windows.
То, как это было реализовано, есть, есть Controller который создает Communicator объекты, назначает номер порта, количество сообщений и т. д. Communicator и вызывает его StartClient способ начать диалог с сервером.
В пределах StartClient метод, каждый Communicator Объект создает соединение с сервером, используя номер порта и URL, указанный в Controller, После установления соединения он внутренне создает поток и вызывает ReadMessages метод, который продолжает чтение с сервера до тех пор, пока счетчик сообщений не будет встречен, а затем закрыт.
В зависимости от условий выполнения может потребоваться повторное использование Communicator объект, чтобы снова поговорить с сервером и, следовательно, ReadMessages метод будет вызван снова.
Первоначально мы звонили Dispose() метод для объектов NetworkStream, StreamReader и StreamWriter, когда ReadMessages метод завершен, но в сценарии переподключения он выдает ошибку "Не удается получить доступ к удаленному объекту". Итак, мы закомментировали Dispose вызов метода для тестирования.
На данный момент он работает нормально, но я обеспокоен тем, что это не лучший способ достичь этой функциональности, поскольку я никогда не избавляюсь от объектов.
Я думал с точки зрения объектного пула: возможно ли иметь пул потоковых объектов, которые могут быть повторно использованы различными потоками?
Одним из способов решения этой проблемы может быть создание нового экземпляра объектов Stream каждый раз, когда Communicator соединяется с сервером, но я думаю, что это будет дорогой операцией.
Не могли бы вы помочь мне определить лучший подход к урегулированию ситуации здесь, чтобы я мог повторно использовать Communicator объект без удара производительности?
1 ответ
Подход будет основан на том, как часто вам нужно читать сообщения - если это время от времени, я бы порекомендовал вам перефакторизовать ваш объект коммуникатора, чтобы сделать операцию "ReadMessages" атомарной - то есть она будет подключаться к серверу, создавать сетевой поток, читать сообщения, а затем распоряжаться каждой вещи.