NetworkStream Pooling - PullRequest
       5

NetworkStream Pooling

1 голос
/ 21 декабря 2010

У меня есть многопоточное приложение, которое связывается с сервером по TCP-соединению. Приложение будет развернуто как служба Windows.

Способ, которым он был реализован, - это Controller, который создает Communicator объекты, назначает номер порта, количество сообщений и т.д. свойств для Communicator и вызывает его метод StartClient, чтобы начать диалог с сервер.

В методе StartClient каждый объект Communicator создает соединение с сервером, используя номер порта и URL-адрес, указанные в Controller. После установления соединения он внутренне создает поток и вызывает метод ReadMessages, который продолжает чтение с сервера до тех пор, пока счетчик сообщений не будет удовлетворен, а затем будет закрыт.

В зависимости от условий выполнения может потребоваться повторное использование объекта Communicator для повторного общения с сервером, и, следовательно, метод ReadMessages будет вызываться снова.

Изначально мы вызывали метод Dispose() для объектов NetworkStream, StreamReader и StreamWriter, когда завершился метод ReadMessages, но в сценарии переподключения он вызывал «Невозможно получить доступ к удаленному объекту» ошибка. Итак, мы прокомментировали вызов метода Dispose для тестирования.

На данный момент все работает нормально, но я обеспокоен тем, что это не лучший способ достичь этой функциональности, поскольку я никогда не избавляюсь от объектов.

Я думал с точки зрения объектного пула: возможно ли иметь пул потоковых объектов, которые могут быть повторно использованы различными потоками?

Одним из способов решения этой проблемы может быть создание нового экземпляра объектов Stream каждый раз, когда Communicator соединяется с сервером, но я думаю, что это будет дорогой операцией.

Не могли бы вы помочь мне определить лучший подход для решения этой ситуации, чтобы я мог повторно использовать объект Communicator без снижения производительности?

1 Ответ

0 голосов
/ 21 декабря 2010

Подход будет основан на том, как часто вам нужно читать сообщения - если это время от времени, я бы порекомендовал вам повторно фактор вашего объекта коммуникатора, чтобы сделать операцию «ReadMessages» атомарной - то есть он будет подключаться к серверу, создать сетевой поток, читать сообщения, а затем распоряжаться всеми вещами.

...