Подтвердить что ты не робот

Шаблоны проектирования сетевых коммуникаций

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

Существуют ли какие-либо хорошо известные шаблоны проектирования для сетевых коммуникаций и в силу этого характер, построение/анализ протокола? Поиск Google не показал много.

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

EDIT:

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

EDIT2:

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

4b9b3361

Ответ 1

Я бы сказал, что целая цепочка ответственности может быть полезна для отправки/приема данных из/в сеть.

Вы создаете серию команд для отправки на сервер от клиента. Каждая команда обрабатывается цепочкой ответственности, а данные добавляются для правильной обработки команды.

При отправке данных цепочка может выглядеть так:

Command   --> Wrap some       --> Encrypt --> Send data
to send       data around 
              the command 
              (source, extra 
              information if 
              needed)

При получении данных цепочка может быть похожей, но наоборот

Receive Data  -->  Decrypt --> Unwrap extra data --> Execute command

Вы можете проверить эту статью для получения дополнительной информации о цепочке ответственности. http://www.vincehuston.org/dp/chain.html

Ответ 2

Это довольно широкий вопрос, и его лечение, вероятно, требует довольно плотной книги.

Я не знаю ни одного такого ресурса самостоятельно, но давайте подумаем об этом и рассмотрим, каковы будут размеры пространства шаблонов сетевой связи:

способ подключения: {на основе подключения, без подключения}

способ взаимодействия: {синхронный, асинхронный}

сложность разговора: {команда-ответ, диалог}

форма сообщения: {freeform-stream, полуструктурированный блок, полностью структурированный блок} ..

Хорошее место для начала - взять протоколы TCP/IP, сопоставить их с указанным выше пространством и взглянуть на реализацию (и) одного или нескольких образцов, которые занимают уникальное положение в вышеупомянутом протоколе -характеристик. Исходный код вашего любимого * nix os будет хорошим местом для просмотра.

Реализации парсеров, вероятно, попадут в две широкие категории: {обработка с использованием командной строки, конечная машина).

Первый (очевидно) более простой из двух и, вероятно, первоначальная реализация (если вы раньше этого не делали).

Последний (скорее всего) более надежный, эффективный (с точки зрения loc) и позволяющий принимать изменения в протоколе (если он все еще подвержен изменениям дизайна).

(Разумеется, основные возможности виртуальных сетей ОС также влияют на реализацию. Возьмите JVM, например: обработка канала на основе NIO будет очень хорошо работать с FSM.)

Надеюсь, что это поможет.

Ответ 3

Я рекомендую: абстрагировать сетевой протокол/с.

Сначала решите, какие функции, модули и интерфейсы API между ними. Затем определите, какой протокол будет передавать данные по сети.

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

Ответ 4

Я не знаю о шаблонах, как таковых, но есть несколько "очевидных" точек отбора. Во-первых, вы хотите использовать ASN.1 или нет (это влияет на целую партию)? Во-вторых, вам нужен человеко-читаемый протокол или двоичный? В-третьих, вам нужны какие-либо аспекты безопасности в вашем протоколе?

Не то, чтобы ответ "хотеть использовать ASN.1" заставит ответить на многие вопросы, касающиеся дизайна протокола.

Ответ 5

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

BitTorrent - очень популярный децентрализованный протокол, который имеет несколько расширений.

OpenSSH - еще один хороший кандидат; он поддерживает согласование функций, несколько типов шифрования и каналы de/muxing.

Протоколы VoIP хороши для потоковых приложений: RTP и H.323

Протоколы сетевой маршрутизации также хороши: BGP (и расширения), LDP, VRRP/CARP.

Ответ 6

Не прошли это тщательно, но я думаю, это хороший документ:

Кроме того, это выглядит как хорошая книга:

Ответ 7

Схема приемника/коннектора: http://www.cs.wustl.edu/~schmidt/PDF/Acceptor.pdf

Сеть фильтров, основанная на цепочке Gof Ответственность, она используется во множестве сетевых стеков/фреймворков.

Состояние машин для PDU кодирования/декодирования.