Максимальное количество одновременно подключенных GPRS модемов

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

Хотелось бы уточнить с чем в первую очередь такие проблемы будут связаны.
Я предполагаю что ограничения могут исходить от:

  • Интернет провайдера
  • Роутера
  • ОС сервера
  • ЛЭРС УЧЕТ

На каком из вышеописанных этапов могут возникнуть проблемы, и как их можно решить?
Вопрос возник ввиду того, что уже на данный момент к одному из наших серверов одновременно подключено 220 модемов USR-GRPS-730, в дальнейшем это число будет только расти и хочется быть готовым к потенциальным проблемам.

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

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

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

Благодарю за развернутый ответ!
Но к сожалению вопрос так и остался открытым.

Нет, это не так. Модемы, о которых идет речь при подаче на него питания сразу устанавливают TCP соединение до сервера и держат его отрытым. При разрыве соединения пытаются его установить заново. Это относится в данный момент ко всему оборудованию производства USR IOT: Ethernet, WiFi, GPRS, 4G конвертеры интерфейсов - все работают по такому принципу в режиме клиента.

Безусловно мы владеем информацией о общем количестве TCP портов, и что некоторые из них зарезервированы. Но по самым грубым прикидкам в нашем распоряжении оказывается несколько десятков тысяч свободных TCP портов, это в разы больше, нежели “пара сотен модемов”, о которых шла речь.

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

К примеру если мы арендуем VDS, установим туда службу опроса через Docker и часть подключений модемов направим на этот виртуальный сервер - поможет ли это в случае нехватки ресурсов?

Просчитать заранее необходимое ЛЭРС УЧЕТ количество ресурсов для обработки большого числа активных подключений GPRS-модемов попросту невозможно, так как это зависит от множества факторов. В подобных случаях можно только ориентироваться на среднее значение потребляемых ресурсов при нормальной работе ЛЭРС УЧЕТ и исходя из этого пробовать увеличивать их пропорционально увеличению количества модемов.
Либо вы можете распределить модемы между несколькими хостами, о чем собственно вы пишите в вашем примере:

В рамках данной темы хотел бы обсудить возможность использования UDP подключения модемов к серверу вместо TCP: поможет ли это снизить нагрузку в части поддержания большого количества постоянно открытых TCP соединений?
Насколько вероятно при этом появление дополнительных проблем при опросе устройств из за отсутствия контроля доставки пакетов? (канал связи GPRS).

Вопрос возник ввиду того, что ПО модемов не позволяет никоим образом сделать выходы на связь периодическими - только постоянно открытое соединение.
Но вот если использовать UDP - то после опроса ЛЭРС может закрыть соединение со своей стороны, при этом модем не будет пытаться переподключиться т.к. он считает что всё еще подключен к серверу.
Далее мы настраиваем автоматическую перезагрузку модема раз в 65535 секунд (максимально доступное значение) и получаем выходы на связь с интервалом 18,2 часа.
Всё вышесказанное касается модема USR-GPRS-730

С учетом того, что протокол TCP реализован на уровне ОС, влияние его использования на производительность Службы опроса просчитать будет проблематично, если это вообще возможно.
Вероятность появления проблем при опросе с использованием UDP тоже просчитать крайне сложно. Она может значительно варьироваться в зависимости от качества связи, которую сложно оценить в принципе.

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

Можно лишь констатировать, что TCP по сравнению с UDP является более стабильным подключением, но немного более требовательным по производительности. И наоборот.

У UDP сетевых подключений нет, в этом режиме ЛЭРС принимает на порту входящие пакеты, идентифицирует по ним модемы и делает для них свои “виртуальные” подключения, которые затем использует для опроса.

Я пока не совсем понимаю, у вас появилась какая-то проблема при использовании TCP? Если пока всё стабильно опрашивается, я не вижу необходимости что-то менять. Если возникнут проблемы, проще действительно арендовать дополнительный сервер и поставить туда службу опроса.

Проблемы при использовании TCP свзяаны с поведением используемых нами gprs модемов (они держат соединение всегда открытым, переподключаются сразу же после разрыва соединения).
В поисках возможного решения я попробовал использовать UDP и на первый взгляд это решает проблему т.к. модем больше не переподключается после “закрытия соединения”(которое виртуальное) лэрсом.
У меня только остаются опасения касательно возможного получения некорректных данных с приборов учета в силу отсутствия контроля доставки и целостности пакетов в UDP.
С другой стороны, сам протокол обмена прибора (например modbus rtu) предполагает наличие контрольной суммы, которая должна помочь избежать недостоверных данных.

Я попробую на нескольких приборах настроить модемы в режим UDP и в дальнейшем сообщу о результатах, думаю это будет полезно

Почти у всех приборов есть контрольная сумма, и у самого UDP она есть, думаю, что проблем тут возникнуть не должно. Проблемы могут начаться если у самих модемов после каких-то сетевых сбоев поменялся, например, UDP порт, и мы теоретически можем послать запросы не тому прибору. Протоколы обмена большинства устройств всё-таки рассчитаны на постоянное подключение.

Но в этом случае модем должен бы отправить нам пакет с идентификацией и служба опроса обновит параметры UDP.