Сетевые системы-в чем разница между "блокирующим" и "неблокирующим" протоколами?

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

8
network-protocols networking

2 ответов

"блокирующий" вызов "блокирует" программу, которая вызывает его до завершения. Ваша программа должна дождаться, пока она сделает (что угодно), прежде чем запустить следующий оператор. Большинство вызовов функций "блокируются", например,set x to 4 + 4 не будет переходить к следующему оператору, пока он не вычислит значение 8 и назначает его x. Аналогично, блокирующий или синхронный сетевой метод будет удерживать вызывающую программу до ее завершения. В случае чего-то вроде " отправить пакет в удаленную систему," это время может измеряться в секундах или дольше, вместо микросекунд (или меньше), которые потребляет арифметика.

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

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

пример блокировки сетевого ввода - вывода:

set web-page to (the result of) get url "http://www.google.com/"
in web-page, find <title>...</title>,
     assign this to google-title;
if not found,
     present a warning, and
     set google-title to "Google"
do something else…

versus:

get url "http://www.google.com/" and call back google-title-callback
do something else…

function google-title-callback, accepts web-page:
    in web-page, find <title>...</title>,
         assign this to google-title;
    if not found,
         present a warning, and
         set google-title to "Google"

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

8

В чем заключается основная проблема?

подсистемы ввода-вывода обычно имеют на порядок большие задержки, чем простая обработка команд (в CPU). Эта задержка также недетерминирована (хотя, конечно, в известных пределах).

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

в качестве обобщения тогда мы говорим о сотрудничающих взаимосвязанных (активных) компонентах. Обычно это отношение master / slave, но это не общий случай, например, это относится и к одноранговому подключению.

+-----+                 +-----------+
| dev | <==== DATA ====>| processor |
|     | <---- ctrl -----| <master>  |
+-----+                 +-----------+

(обратите внимание, что "устройство" может быть памятью, сетью, диском или другой процесс. Далее обратите внимание, что здесь есть 3 подсистемы, "шина" или "соединение" между двумя одноранговыми узлами также является системой с задержками, пропускной способностью, емкостью и т. д.)

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

  • Блокировку И Без Блокировки

эти термины адрес называть семантикой.

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

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

  • Синхронный И Асинхронный

эти термины адресу шаблоны взаимодействие (протокол).

в синхронном взаимодействии два компонента будут действовать в lock-step, и взаимодействие полностью детерминировано. в принципе, мы можем сказать, что существует известный, детерминированный и конечный набор действий, которые будут иметь место в синхронном обмене между компонентами.

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

было бы, вероятно, уточнить, чтобы добавить "ответ" на эти термины, e.g "синхронный ответ", поскольку это и полностью излагает общую идею, и устраняет неопределенность синхронизации от блокировки (что является общей концептуальной ошибкой).

  • Примечание

Per выше, очевидно у нас есть пространство проектирования системы, которое является перестановкой {block, non-block} X {synch, asynch}. Е. Г. система мая используйте неблокирующую семантику вызовов с асинхронным протоколом.

Обсуждение

но, будучи системными выродками, нам также нравится эффективность и производительность, да?

на нашей диаграмме выше мы отмечаем 3 Различные (и обе независимые) подсистемы. Было бы неплохо, если бы "процессор" выше мог сказать "шине ""отправить xyz в dev" и не подождите, пока автобус не скажет: "Хорошо, я сделал это"? Это был бы неблокирующий звонок. (Обратите внимание, что он никоим образом не адресует синхронизацию или асинхронный протокол!)

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

5