Масштабируемость TCP-keep-alive

Question

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

Какие существуют аргументы относительно масштабируемости использования TCP keep-alive таким образом?

Мой альтернативный подход заключается в использовании модели публикации / подписки, при которой узлы отправляют новые услуги в сеть по мере их появления, а их одноранговые узлы кэшируют их, когда хотят подписаться на услугу. Это звучит выполнимо?

Answer 1

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

Относительно вашего второго вопроса, поскольку TCP-сокеты и keep-alive - это всего лишь концепция, нет никакой (или очень небольшой) внутренней стоимости наличия такого контракта keep-alive. На практике YMMV, поскольку разные реализации сокетов требуют разных ресурсов, и могут потребоваться другие действия, чтобы сохранить канал открытым. Однако существует много реализаций, которые требуют очень мало ресурсов для открытых сокетов (например, select () - введите).

Служба обнаружения (публикация / подписка на службы) наиболее целесообразна, если существует много разработчиков одного и того же типа службы, и вы не можете (или не хотите) прогнозировать статически, где они появятся.

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

Answer 2

Если ваш механизм TCP Keep Alive используется только для отслеживания доступности службы (т. Е. Вы никогда не передаете запрос / ответ службы через эти соединения), использование сокетов TCP, безусловно, является чрезмерным уничтожением. Сокеты TCP требуют значительных ресурсов.

Более масштабируемым методом может быть использование модели публикации / подписки, которая использует UDP-сообщения публикации через регулярные промежутки времени для объявления о продолжении существования службы. Вы также можете использовать сообщение об отказе в обслуживании, опубликованное на отключающем узле, чтобы изящно объявить об окончании обслуживания.

Если пойти дальше, если вы хотите добиться оптимальности с действительно крупномасштабными сетями и готовы потратить некоторое время и усилия, рассмотрите структурированный P2P-механизм, такой как DHT .

Answer 3

Да, использование keep live кажется плохой идеей для любой P2P-сети. Я не только буду держать соединения открытыми только во время передачи данных, я также буду хранить обновления состояния узлов в разных сокетах, чтобы не мешать передаче файлов.