Сохраняется ли 140 TCP-соединений? - PullRequest
4 голосов
/ 02 ноября 2011

В настоящее время мы исследуем наиболее эффективный способ связи между 120-140 встроенными аппаратными устройствами, работающими на платформе .NET Micro, и сервером.

Каждое встроенное устройство должно отправлять и запрашивать информацию с сервера на регулярной основе, все в режиме реального времени через TCP.

Мой вопрос такой: было бы лучше инициализировать 140?TCP-соединения с сервером, а затем зависнуть на этих соединениях, или инициализировать новое соединение для каждого запроса и от устройств?Будет ли удерживать и управлять 140 TCP-соединениями нагрузку на сервер?

Когда сервер обнаруживает новые данные в базе данных, он должен отправить эту новую информацию на устройства 1 .. * (информация предназначена для определенных устройств), если я удерживаюсь на 140 соединениях, мне нужно будет сделатьпоиск правильного соединения каждый раз, когда мне нужно было отправлять информацию, а не просто отправлять на IP: PORT, связанный с новыми данными.

Я предполагаю, что еще один, возможно, глупый вопрос, будет ли это фактически зависать140 TCP соединений на один порт?

Любые предложения / комментарии приветствуются!

Ответы [ 3 ]

3 голосов
/ 02 ноября 2011

Как правило, вам лучше поддерживать соединения как можно дольше.Если у вас есть каждое устройство, открывающее соединение каждый раз, когда оно отправляет сообщение, вы можете эффективно выполнить DoS'-работу с сервером, поскольку в результате у него будет множество сокетов в состоянии TIME_WAIT, занимающих место в его таблицах.

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

Современные операционные системы могут иметь большие буферы, чем те, которые я на самом делестолкнулся с эффектом DoS, но, по сути, не самая лучшая идея - использовать множество подобных соединений.

На клиентской стороне все может быть довольно сложно, особенно когда устройство имеет тенденцию прозрачно переходить в спящий режим.приложение, потому что это означает, что время соединения истекает, пока приложение думает, что они все еще открыты.Когда мы сделали это, мы получили довольно сложный сетевой код, потому что нам нужно было учитывать тот факт, что сокеты могут (и будут) выходить из строя, как само собой разумеющееся, и нам просто нужно было установить новое соединение и повторить попытку отправки сообщения.,Вы просто убираете этот код в свои библиотеки и забываете о нем, как только он это сделает.

На самом деле на практике наше первоначальное приложение имело еще более сложный код, потому что он имел дело с сетевой библиотекой, которая была полуосознаваемой.из-за того, что устройства были остановлены и пытались повторно отправить сообщения о сбое, что иногда означало, что одно и то же сообщение было отправлено дважды.Мы закончили тем, что сделали дополнительный уровень связи сверху, чтобы гарантировать, что дубликаты были отклонены.Если вы используете C # или обычные сокеты в стиле BSD, у вас не должно быть этой проблемы, хотя я предполагаю.Это была проприетарная библиотека, которая управляла переподключениями, но вызывала головные боли при повторных отправках, и это неуместное время ожидания по умолчанию.

2 голосов
/ 02 ноября 2011

Если вы говорите о системе с аппаратными устройствами, то я советую закрывать соединение каждый раз, когда клиент заканчивает отправку данных.

Чтобы клиент получал обновления с сервера, он может в течение 5 секунд ждать поступления любых данных с сервера. Если данные получены в течение / до этого периода времени, закройте соединение и обработайте данные. Если нет, закройте соединение и подождите после отправки следующего набора данных.

Таким образом, масштабирование становится намного проще. Сохранение открытых соединений всегда приводит к нагрузке на ресурсы, и, по моему мнению, в этом нет необходимости, если только это не какое-то спасительное устройство, такое как монитор сердечного ритма, монитор подачи кислорода и т. Д.,

2 голосов
/ 02 ноября 2011

Обычно к серверу можно подключить более 140 "клиентов" (то есть с приличной сетью / HW / RAM) ...

Я рекомендую всегда проверять подобные вещи с реальными сценариями (загрузка и т. Д.), Чтобы принять решение, поскольку есть такие аспекты, как сеть (производительность, стабильность ...), HW (RAM сервера и т. Д.) И SW (что делает сервер точно делает?) это может проверить только ты.

В зависимости от протокола, вы можете / должны даже использовать механизм тайм-аута / переподключения.

Поиск, который вы имеете в виду, будет очень быстрым - просто используйте ConcurrentDictionary для хранения необходимой информации с ключом IP: PORT (при условии, что сервер работает на полной версии .NET 4).

Некоторые ссылки см .:

РЕДАКТИРОВАТЬ - согласно комментариям:

Удержание соединения TCP / IP не требует большой обработки на стороне клиента ... это стоит немного памяти. Я бы рекомендовал провести небольшой тест (1-2 клиента), чтобы проверить это предположение для вашего конкретного случая.

...