Распределенные вычисления на основе стека протоколов TCP/IP
Рассмотрим особенности организации распределенных вычислений. От централизованных они отличаются наличием связи между процессами. Связи между централизованными процессами предполагают наличие разделяемой памяти. Классический пример создания буферов чтения/записи при обращении к массиву данных.
Основой взаимодействия распределенных вычислений служит посылка и прием сообщений. Уже на двух программных примитивах (посылка и прием) можно построить достаточно сложные средства сетевых коммуникаций, например, программные системы в архитектуре Клиент/Сервер или вызов удаленных процедур (Remote Procedure Call). Рассмотрим эти средства более подробно. Средства удаленного вызова процедур предназначены для облегчения создания распределенных вычислений. Реализация удаленных вызовов существенно сложнее реализации вызовов локальных процедур. Начнем с того, что вызывающая и вызываемая процедуры выполняются на разных машинах. Они имеют разные адресные пространства и это создает дополнительные проблемы при передаче параметров и результатов, особенно для машин разных классов. Приложения RPC не могут рассчитывать на разделяемую память, следовательно, невозможно передать указатель на стек, значения параметров должны быть посланы с одного компьютера на другой. Другая отличительная особенность RPC — использование какой-либо системы связи между компьютерами. Однако эта связь очень прозрачна, то есть программист, проектирующий RPC-ориентированное приложение, не занимается низкоуровневыми протоколами. В реализации RPC участвуют, как минимум, два процесса и при аварийном завершении одного из них другой в ожидании ответа будет крутиться вхолостую.
Вопросы связи процессов (посредством передачи параметров или удаленных вызовов) тесно связаны с вопросами синхронизации процессов. Синхронизация необходима процессам для организации совместно используемых ресурсов. Рассмотрим основные типы алгоритмов, которые могут быть использованы в распределенных системах:
1. Централизованный алгоритм. Один из процессов выбирается в качестве координатора. Когда какой-либо процесс хочет войти в критическую секцию, он посылает запрос координатору и ждет ответа. Если в этот момент ни один из процессов не находится в критической секции, то координатор присылает ответ с разрешением. Если же некоторый процесс выполняет критическую секцию, ответ не присылается. Он ставится в очередь и после освобождения критической секции ему присылается ответ-разрешение.
2. Распределенный алгоритм. Если процесс хочет войти в критическую секцию, он формирует сообщение, содержащее имя нужной ему критической секции, номер процесса и текущее значение времени. Это сообщение рассылается всем другим процессам. Возможны три варианта: принимающий процесс находится не в критической секции — отсылается разрешение; процесс находится в критической секции — он не отправляет никакого ответа и ставит запрос в очередь; процесс хочет войти в критическую секцию, но еще не сделал этого — он сравнивает временную отметку поступившего сообщения со значением времени, которое содержится в его собственном запросе, разосланном всем другим процессам. Если время поступившего к нему сообщения меньше, то есть его собственный запрос возник позже, он посылает сообщение-разрешение. В противном случае он не посылает ничего и ставит поступившее сообщение в очередь. Процесс может войти в критическую секцию только в том случае, если он получил ответные сообщения-разрешения от всех остальных процессов. Ели процесс покидает критическую секцию, он посылает разрешение всем процессам из своей очереди и очищает ее.
3. Алгоритм Token Ring. Все процессы в системе образуют логическое кольцо, то есть каждый процесс знает номер своей позиции в кольце, а также номер ближайшего к нему процесса. Когда кольцо инициализируется, процессу под номером 0 передается маркер (token). Маркер циркулирует по кольцу. Он переходит от процесса n к процессу n+1. Когда процесс получает маркер, он анализирует ситуацию, не надо ли ему войти в критическую секцию. Если да, он оставляет маркер у себя и начинает выполнение критического участка программы, после выхода из него он передает маркер дальше по кольцу. Если же процесс не заинтересован во вхождении в критическую секцию, он сразу же передает маркер дальше по кольцу. То есть, если ни один из процессов не заинтересован во вхождении в критическую секцию, маркер просто циркулирует по кольцу.
Сравним эти три алгоритма. Централизованный алгоритм является наиболее простым и эффективным. При его использовании требуется только три сообщения. При использовании распределенного алгоритма для выполнения одной критической секции требуется послать (n-1) сообщений-запросов (где n-число процессов), по одному на каждый процесс, и получить (n-1) разрешений, то есть всего необходимо 2(n-1) сообщений. В алгоритме Token Ring число сообщений переменно: от одного, если каждый процесс входит в критическую секцию, до бесконечно большого числа при циркуляции маркера по кольцу. К сожалению, алгоритмы такого типа плохо защищены от отказов.
Приведем основные черты современного RPC-протокола:
‰ машинно-независимый инструментарий, позволяющий создавать приложения, способные обмениваться данными с приложениями, запущенными на различных типах ОС;
‰ проработанная технология создания Клиент/Серверных приложений;
‰ компилятор RPC-протокола, который позволяет скрыть низкоуровневую реализацию межсетевого обмена данными;
‰ аутентификация, дающая возможность строить распределенные приложения, обеспечивающие авторизированный доступ;
‰ набор высокоуровневых библиотек, позволяющий достаточно легко работать с такими сетевыми объектами, как пользователи (users), устройства и компьютеры, подключенные к сети (hosts), почтовые ящики (mailboxes).
история и стандарты распределенных вычислений
История создания RPC своими корнями уходит в далекие 80-е годы. Основой этой технологии считаются "рекомендации по сетевым вычислениям" фирмы Apollo Computers, известные под аббревиатурой NCA (Network Computing Architecture).
Современный мир распределенных вычислений разбит на два стандарта: с одного берега находится ONC (Open Network Computing), с другого — NCS (Network Computing Systems). В лагере ONC находятся такие гиганты, как Sun, AT&T, Novell и Netwise, к сторонникам NCS можно отнести HP, IBM, DEC, Microsoft (рис.1).
Одним из плюсов ONC является открытость этой системы: исходные коды доступны широкой общественности. NCS и ONC в общем очень похожи друг на друга. Оба эти стандарта входят в состав различных операционных систем и инструментальных средств. NCS была создана как часть большой концепции распределенных вычислений, разработанной двумя компаниями Apollo Computers и HP. NCS — законченная технология, готовая к применению. Она является своего рода комбинацией двух продуктов — NCS/NCK (Network Computing Kernel) и NCS/NIDL (Network Interface Description Language). NCK — это библиотека времени-выполнения (run-time), которая включает поддержку RPC и сетевой менеджер ресурсов с аутентификацией, называемый Location Broker. По этой спецификации низкоуровневые RPC API-функции работают через свой формат данных NDR (Network Data Representation). Другой компонент NCS — NIDL представляет собой набор инструментов для построения распределенных приложений, включающий компилятор протокола (то есть компилятор, заменяющий локальные вызовы на RPC вызовы). Он транслирует данные формата языка Си в NCA-данные и обеспечивает совместную работу NCK с клиентскими и серверными частями приложения. Немного о Location Broker: он разделен на два интерфейса — локальный и глобальный (LLB и GLB). LLB выдает информацию о ресурсах конкретной ПЭВМ, на которой он установлен. GLB обеспечивает информацией о сети в целом. Эти брокеры получают информацию о сетевых ресурсах непосредственно из транспортного протокола NCS RPC, то есть клиент всегда сможет узнать, доступен ли сервер. Также брокер может выполнять аутентификационные задачи, проверяя, использует ли программное обеспечение клиента лицензионное соглашение NCS RPC. Наборы NCS/NCK и NCS/NIDL поддерживаются такими операционными системами, как HP-UX, SunOS, VAX/VMS и VAX/ULTRIX.
ONC. Родителем концепции ONC является компания Sun. Концепция включает следующие уровни: XDR (External Data Representation) — представление данных для транспортного протокола, которыми обмениваются Клиент и Сервер; NIS (Network Information Server) — который очень похож на Location Broker из NCS; RPCGEN — компилятор вызовов функций в стиле языка Си на межсетевые вызовы RPC. Компилятор протокола — один из важных инструментов построения распределенных вычислений. Две технологии — NCS и ONC включают компиляторы протоколов: NIDL и RPCGEN соответственно. Оба используют синтаксис, очень похожий на синтаксис языка Си с директивами для препроцессора и структурным описанием блоков. NCS также поддерживает и Паскалеподобный синтаксис. ONC может включать сетевую файловую систему NFS (Network File Systems) с автоматическим подключением сетевых томов (дисков) в файловую систему локальной ПЭВМ, блокировкой файлов, разграничением прав доступа и мониторингом работы файловой системы.
RPC — языковая модель
Не так давно программы представляли собой монолитные блоки кода, которые были разбиты на функции, и вызовы осуществлялись в пределах адресного пространства, отведенного программе. Путем создания загружаемых библиотек можно было часть программного кода оформить в такую библиотеку и при необходимости загружать/выгружать ее в ОЗУ ПЭВМ (рис. 2).
RPC предоставляет иной уровень программирования: программный код можно вызывать и на удаленной ПЭВМ, подключенной каким-либо образом к сети. Рассмотрим, как происходит RPC вызов. Программист создает клиентскую и серверную часть приложения (в качестве серверной части может выступать системный сервис, входящий в поставку соответствующих операционных систем). Клиентская и серверная части запускаются на различных ПЭВМ, соединенных в сеть. Впрочем, это можно промоделировать и на одной ПЭВМ. Клиентская часть вызывает код, расположенный на ПЭВМ с серверной частью приложения. Функциональный вызов (1) перехватывает так называемая заглушка (Program Stub), которая перенаправляет локальный вызов в RPC-библиотеку времени-выполнения (2), в ней происходит преобразование данных под существующий транспортный протокол (3). Данные и служебная информация переносятся по сети (4), декодируются в RPC-библиотеке времени-выполнения, расположенной на ПЭВМ с серверной частью (5), и через заглушку попадают на серверную часть приложения. В серверной ПЭВМ запускается соответствующий запросу программный код и результаты его работы по уже известной схеме передаются в клиентскую часть (рис. 3).
Библиотеки времени-выполнения RPC-протокола многих фирм могут подлинковываться к приложению, и при его поставке нет необходимости в переносе этих библиотек.
RPC может работать и локально. При локальном вызове весь процесс передачи параметров происходит в одном адресном пространстве. Этапы создания RPC- приложения в соответствии с этой моделью приведены на рис. 4.
При построении RPC-ориентированных приложений необходимо выбирать транспортный протокол, в который будут инкапсулироваться RPC-вызовы. Рассмотрим основные достоинства и недостатки двух базовых транспортов стека протоколов TPC/IP: TCР (Transmission Control Protocol) и UDP (Usr Datagram Protocol). Протокол UDP (RFC-768) предоставляет прикладным процессам транспортные услуги, он обеспечивает доставку дейтограмм, не требуя подтверждения их получения. Он не требует "установки соединения". К IP-пакету на уровне UDP добавляется порт отправителя, порт получателя и длина UDP-дейтограммы плюс контрольная сумма для обеспечения целостности данных. При доставке IP-дейтограммы требуется IP-адрес машины- приемника, в случае UDP-протокола необходимы еще и номера портов. Порт — это логический канал для установки соединения. UDP-порты нумеруются, начиная с нуля. Прикладной процесс, предоставляющий услуги, ожидает сообщения, направленного в порт, специально выделенный для этих услуг. Номера портов 0—255 стандартизированы и их в прикладных процессах использовать не рекомендуется, но и в интервале 255—1023 многие порты уже заняты, поэтому прежде чем использовать какой-либо порт рекомендуется заглянуть в RFC-1700. Большинство приложений TCP/IP используют номера портов в диапазоне 1024—5000. Например: 21 — FTP (протокол передачи файлов), 23 — TELNET (подключение терминалов), 25 — SMTP (протокол передачи почтовых сообщений).
Протокол TCP (RFC-793, 1323) в отличие от UDP осуществляет доставку дейтограмм, называемых сегментами, в виде байтовых потоков с установленным соединением. Протокол TCP применяется в том случае, когда требуется гарантированная доставка сообщений. Он использует контрольные суммы пакетов для проверки их целостности и освобождает прикладные процессы от необходимых тайм-аутов и повторных передач для обеспечения надежности. Но TCP очень "тяжелый" протокол. Для посылки одного байта информации нужно послать 41-байтовый пакет (20 байт IP-заголовка, 20 байт TCP-заголовка плюс байт данных). Хотя TCP обычно старается совместить посылку информации в "одном направлении", ожидание может достигать 200 мс (максимум 500 мс). TCP — протокол с очень низким КПД.
Более подробно с RPC можно ознакомиться в следующих документах:
RFC-1050 RPC: Remote Procedure Call Protocol specification. Sun Microsystems, 1988. (Status: HISTORIC)
RFC-1057 RPC: Remote Procedure Call Protocol specification: Version 2. Sun Microsystems, 1988. (Status: INFORMATIONAL)
RFC-1831 RPC: Remote Procedure Call Protocol Specification Version 2, 1995. (Status: PROPOSED STANDARD)
RFC-1833 Binding Protocols for ONC RPC Version 2, 1995. (Status: PROPOSED STANDARD)
RFC-2695 Authentication Mechanisms for ONC RPC, 1999. (Status: INFORMATIONAL)
Андрей Лапоуховa.lapouhov@belcaf.com
Основой взаимодействия распределенных вычислений служит посылка и прием сообщений. Уже на двух программных примитивах (посылка и прием) можно построить достаточно сложные средства сетевых коммуникаций, например, программные системы в архитектуре Клиент/Сервер или вызов удаленных процедур (Remote Procedure Call). Рассмотрим эти средства более подробно. Средства удаленного вызова процедур предназначены для облегчения создания распределенных вычислений. Реализация удаленных вызовов существенно сложнее реализации вызовов локальных процедур. Начнем с того, что вызывающая и вызываемая процедуры выполняются на разных машинах. Они имеют разные адресные пространства и это создает дополнительные проблемы при передаче параметров и результатов, особенно для машин разных классов. Приложения RPC не могут рассчитывать на разделяемую память, следовательно, невозможно передать указатель на стек, значения параметров должны быть посланы с одного компьютера на другой. Другая отличительная особенность RPC — использование какой-либо системы связи между компьютерами. Однако эта связь очень прозрачна, то есть программист, проектирующий RPC-ориентированное приложение, не занимается низкоуровневыми протоколами. В реализации RPC участвуют, как минимум, два процесса и при аварийном завершении одного из них другой в ожидании ответа будет крутиться вхолостую.
Вопросы связи процессов (посредством передачи параметров или удаленных вызовов) тесно связаны с вопросами синхронизации процессов. Синхронизация необходима процессам для организации совместно используемых ресурсов. Рассмотрим основные типы алгоритмов, которые могут быть использованы в распределенных системах:
1. Централизованный алгоритм. Один из процессов выбирается в качестве координатора. Когда какой-либо процесс хочет войти в критическую секцию, он посылает запрос координатору и ждет ответа. Если в этот момент ни один из процессов не находится в критической секции, то координатор присылает ответ с разрешением. Если же некоторый процесс выполняет критическую секцию, ответ не присылается. Он ставится в очередь и после освобождения критической секции ему присылается ответ-разрешение.
2. Распределенный алгоритм. Если процесс хочет войти в критическую секцию, он формирует сообщение, содержащее имя нужной ему критической секции, номер процесса и текущее значение времени. Это сообщение рассылается всем другим процессам. Возможны три варианта: принимающий процесс находится не в критической секции — отсылается разрешение; процесс находится в критической секции — он не отправляет никакого ответа и ставит запрос в очередь; процесс хочет войти в критическую секцию, но еще не сделал этого — он сравнивает временную отметку поступившего сообщения со значением времени, которое содержится в его собственном запросе, разосланном всем другим процессам. Если время поступившего к нему сообщения меньше, то есть его собственный запрос возник позже, он посылает сообщение-разрешение. В противном случае он не посылает ничего и ставит поступившее сообщение в очередь. Процесс может войти в критическую секцию только в том случае, если он получил ответные сообщения-разрешения от всех остальных процессов. Ели процесс покидает критическую секцию, он посылает разрешение всем процессам из своей очереди и очищает ее.
3. Алгоритм Token Ring. Все процессы в системе образуют логическое кольцо, то есть каждый процесс знает номер своей позиции в кольце, а также номер ближайшего к нему процесса. Когда кольцо инициализируется, процессу под номером 0 передается маркер (token). Маркер циркулирует по кольцу. Он переходит от процесса n к процессу n+1. Когда процесс получает маркер, он анализирует ситуацию, не надо ли ему войти в критическую секцию. Если да, он оставляет маркер у себя и начинает выполнение критического участка программы, после выхода из него он передает маркер дальше по кольцу. Если же процесс не заинтересован во вхождении в критическую секцию, он сразу же передает маркер дальше по кольцу. То есть, если ни один из процессов не заинтересован во вхождении в критическую секцию, маркер просто циркулирует по кольцу.
Сравним эти три алгоритма. Централизованный алгоритм является наиболее простым и эффективным. При его использовании требуется только три сообщения. При использовании распределенного алгоритма для выполнения одной критической секции требуется послать (n-1) сообщений-запросов (где n-число процессов), по одному на каждый процесс, и получить (n-1) разрешений, то есть всего необходимо 2(n-1) сообщений. В алгоритме Token Ring число сообщений переменно: от одного, если каждый процесс входит в критическую секцию, до бесконечно большого числа при циркуляции маркера по кольцу. К сожалению, алгоритмы такого типа плохо защищены от отказов.
Приведем основные черты современного RPC-протокола:
‰ машинно-независимый инструментарий, позволяющий создавать приложения, способные обмениваться данными с приложениями, запущенными на различных типах ОС;
‰ проработанная технология создания Клиент/Серверных приложений;
‰ компилятор RPC-протокола, который позволяет скрыть низкоуровневую реализацию межсетевого обмена данными;
‰ аутентификация, дающая возможность строить распределенные приложения, обеспечивающие авторизированный доступ;
‰ набор высокоуровневых библиотек, позволяющий достаточно легко работать с такими сетевыми объектами, как пользователи (users), устройства и компьютеры, подключенные к сети (hosts), почтовые ящики (mailboxes).
история и стандарты распределенных вычислений
История создания RPC своими корнями уходит в далекие 80-е годы. Основой этой технологии считаются "рекомендации по сетевым вычислениям" фирмы Apollo Computers, известные под аббревиатурой NCA (Network Computing Architecture).
Современный мир распределенных вычислений разбит на два стандарта: с одного берега находится ONC (Open Network Computing), с другого — NCS (Network Computing Systems). В лагере ONC находятся такие гиганты, как Sun, AT&T, Novell и Netwise, к сторонникам NCS можно отнести HP, IBM, DEC, Microsoft (рис.1).
Одним из плюсов ONC является открытость этой системы: исходные коды доступны широкой общественности. NCS и ONC в общем очень похожи друг на друга. Оба эти стандарта входят в состав различных операционных систем и инструментальных средств. NCS была создана как часть большой концепции распределенных вычислений, разработанной двумя компаниями Apollo Computers и HP. NCS — законченная технология, готовая к применению. Она является своего рода комбинацией двух продуктов — NCS/NCK (Network Computing Kernel) и NCS/NIDL (Network Interface Description Language). NCK — это библиотека времени-выполнения (run-time), которая включает поддержку RPC и сетевой менеджер ресурсов с аутентификацией, называемый Location Broker. По этой спецификации низкоуровневые RPC API-функции работают через свой формат данных NDR (Network Data Representation). Другой компонент NCS — NIDL представляет собой набор инструментов для построения распределенных приложений, включающий компилятор протокола (то есть компилятор, заменяющий локальные вызовы на RPC вызовы). Он транслирует данные формата языка Си в NCA-данные и обеспечивает совместную работу NCK с клиентскими и серверными частями приложения. Немного о Location Broker: он разделен на два интерфейса — локальный и глобальный (LLB и GLB). LLB выдает информацию о ресурсах конкретной ПЭВМ, на которой он установлен. GLB обеспечивает информацией о сети в целом. Эти брокеры получают информацию о сетевых ресурсах непосредственно из транспортного протокола NCS RPC, то есть клиент всегда сможет узнать, доступен ли сервер. Также брокер может выполнять аутентификационные задачи, проверяя, использует ли программное обеспечение клиента лицензионное соглашение NCS RPC. Наборы NCS/NCK и NCS/NIDL поддерживаются такими операционными системами, как HP-UX, SunOS, VAX/VMS и VAX/ULTRIX.
ONC. Родителем концепции ONC является компания Sun. Концепция включает следующие уровни: XDR (External Data Representation) — представление данных для транспортного протокола, которыми обмениваются Клиент и Сервер; NIS (Network Information Server) — который очень похож на Location Broker из NCS; RPCGEN — компилятор вызовов функций в стиле языка Си на межсетевые вызовы RPC. Компилятор протокола — один из важных инструментов построения распределенных вычислений. Две технологии — NCS и ONC включают компиляторы протоколов: NIDL и RPCGEN соответственно. Оба используют синтаксис, очень похожий на синтаксис языка Си с директивами для препроцессора и структурным описанием блоков. NCS также поддерживает и Паскалеподобный синтаксис. ONC может включать сетевую файловую систему NFS (Network File Systems) с автоматическим подключением сетевых томов (дисков) в файловую систему локальной ПЭВМ, блокировкой файлов, разграничением прав доступа и мониторингом работы файловой системы.
RPC — языковая модель
Не так давно программы представляли собой монолитные блоки кода, которые были разбиты на функции, и вызовы осуществлялись в пределах адресного пространства, отведенного программе. Путем создания загружаемых библиотек можно было часть программного кода оформить в такую библиотеку и при необходимости загружать/выгружать ее в ОЗУ ПЭВМ (рис. 2).
RPC предоставляет иной уровень программирования: программный код можно вызывать и на удаленной ПЭВМ, подключенной каким-либо образом к сети. Рассмотрим, как происходит RPC вызов. Программист создает клиентскую и серверную часть приложения (в качестве серверной части может выступать системный сервис, входящий в поставку соответствующих операционных систем). Клиентская и серверная части запускаются на различных ПЭВМ, соединенных в сеть. Впрочем, это можно промоделировать и на одной ПЭВМ. Клиентская часть вызывает код, расположенный на ПЭВМ с серверной частью приложения. Функциональный вызов (1) перехватывает так называемая заглушка (Program Stub), которая перенаправляет локальный вызов в RPC-библиотеку времени-выполнения (2), в ней происходит преобразование данных под существующий транспортный протокол (3). Данные и служебная информация переносятся по сети (4), декодируются в RPC-библиотеке времени-выполнения, расположенной на ПЭВМ с серверной частью (5), и через заглушку попадают на серверную часть приложения. В серверной ПЭВМ запускается соответствующий запросу программный код и результаты его работы по уже известной схеме передаются в клиентскую часть (рис. 3).
Библиотеки времени-выполнения RPC-протокола многих фирм могут подлинковываться к приложению, и при его поставке нет необходимости в переносе этих библиотек.
RPC может работать и локально. При локальном вызове весь процесс передачи параметров происходит в одном адресном пространстве. Этапы создания RPC- приложения в соответствии с этой моделью приведены на рис. 4.
При построении RPC-ориентированных приложений необходимо выбирать транспортный протокол, в который будут инкапсулироваться RPC-вызовы. Рассмотрим основные достоинства и недостатки двух базовых транспортов стека протоколов TPC/IP: TCР (Transmission Control Protocol) и UDP (Usr Datagram Protocol). Протокол UDP (RFC-768) предоставляет прикладным процессам транспортные услуги, он обеспечивает доставку дейтограмм, не требуя подтверждения их получения. Он не требует "установки соединения". К IP-пакету на уровне UDP добавляется порт отправителя, порт получателя и длина UDP-дейтограммы плюс контрольная сумма для обеспечения целостности данных. При доставке IP-дейтограммы требуется IP-адрес машины- приемника, в случае UDP-протокола необходимы еще и номера портов. Порт — это логический канал для установки соединения. UDP-порты нумеруются, начиная с нуля. Прикладной процесс, предоставляющий услуги, ожидает сообщения, направленного в порт, специально выделенный для этих услуг. Номера портов 0—255 стандартизированы и их в прикладных процессах использовать не рекомендуется, но и в интервале 255—1023 многие порты уже заняты, поэтому прежде чем использовать какой-либо порт рекомендуется заглянуть в RFC-1700. Большинство приложений TCP/IP используют номера портов в диапазоне 1024—5000. Например: 21 — FTP (протокол передачи файлов), 23 — TELNET (подключение терминалов), 25 — SMTP (протокол передачи почтовых сообщений).
Протокол TCP (RFC-793, 1323) в отличие от UDP осуществляет доставку дейтограмм, называемых сегментами, в виде байтовых потоков с установленным соединением. Протокол TCP применяется в том случае, когда требуется гарантированная доставка сообщений. Он использует контрольные суммы пакетов для проверки их целостности и освобождает прикладные процессы от необходимых тайм-аутов и повторных передач для обеспечения надежности. Но TCP очень "тяжелый" протокол. Для посылки одного байта информации нужно послать 41-байтовый пакет (20 байт IP-заголовка, 20 байт TCP-заголовка плюс байт данных). Хотя TCP обычно старается совместить посылку информации в "одном направлении", ожидание может достигать 200 мс (максимум 500 мс). TCP — протокол с очень низким КПД.
Более подробно с RPC можно ознакомиться в следующих документах:
RFC-1050 RPC: Remote Procedure Call Protocol specification. Sun Microsystems, 1988. (Status: HISTORIC)
RFC-1057 RPC: Remote Procedure Call Protocol specification: Version 2. Sun Microsystems, 1988. (Status: INFORMATIONAL)
RFC-1831 RPC: Remote Procedure Call Protocol Specification Version 2, 1995. (Status: PROPOSED STANDARD)
RFC-1833 Binding Protocols for ONC RPC Version 2, 1995. (Status: PROPOSED STANDARD)
RFC-2695 Authentication Mechanisms for ONC RPC, 1999. (Status: INFORMATIONAL)
Андрей Лапоуховa.lapouhov@belcaf.com
Сетевые решения. Статья была опубликована в номере 08 за 2000 год в рубрике RFC
