Распределенные вычисления: технология Microsoft RPC. Часть1. Фертиков В.В. - 4 стр.

UptoLike

Составители: 

4
отдельный процесс или виртуальную машину , поэтому, не дожидаясь оконча-
ния работы предыдущих запросов, сразу же может принимать следующие.
Протокол RPC может использовать несколько различных транспортных
протоколов. В обязанности RPC-протокола входит только обеспечение стан -
дартов и интерпретация передачи сообщений . Достоверность и надежность пе-
редачи сообщений целиком обеспечивается транспортным уровнем . Однако
RPC может контролировать выбор и некоторые функции транспортного прото -
кола. RPC никогда не дублирует функции транспортных протоколов. Если, на-
пример , RPC работает поверх TCP, все заботы о надежности и достоверности
соединения RPC возлагает на TCP. Если протокол RPC установлен поверх UDP,
он может обеспечивать дополнительные собственные функции обеспечения га-
рантированной доставки сообщений .
Идея , положенная в основу RPC, состоит в том , чтобы сделать вызов уда-
ленной процедуры выглядящим по возможности так же, как и вызов локальной
процедуры . Другими словами сделать RPC прозрачным: вызывающей проце-
дуре не требуется знать, что вызываемая процедура находится на другой маши-
не, и наоборот. Реализация удаленных вызовов существенно сложнее реализа-
ции вызовов локальных процедур. Начнем с того , что поскольку вызывающая и
вызываемая процедуры выполняются на разных машинах , то они имеют разные
адресные пространства, и это создает проблемы при передаче параметров и ре-
зультатов, особенно если машины не идентичны . Так как RPC не может рассчи-
тывать на разделяемую память, то это означает, что параметры RPC не должны
содержать указателей на ячейки нестековой памяти и что значения параметров
должны копироваться с одного компьютера на другой . Следующим отличием
RPC от локального вызова является то , что он обязательно использует нижеле-
жащую систему связи, однако это не должно быть явно видно ни в определении
процедур, ни в самих процедурах . Удаленность вносит дополнительные про-
блемы. Выполнение вызывающей программы и вызываемой локальной проце-
дуры в одной машине реализуется в рамках единого процесса. Но в реализации
RPC участвуют как минимум два процесса по одному в каждой машине. В
случае аварийного завершения какого - либо из них могут возникнуть следую-
щие ситуации: при аварии вызывающей процедуры , удаленно вызванные про-
цедуры станут «осиротевшими» , а при аварийном завершении удаленных про-
цедур станут «обездоленными родителями» вызывающие процедуры , которые
будут безрезультатно ожидать ответа от удаленных процедур. Кроме того , су -
ществует ряд проблем , связанных с неоднородностью языков программирова-
ния и операционных сред : структуры данных и структуры вызова процедур,
поддерживаемые в каком -либо одном языке программирования, не поддержи-
ваются точно так же во всех других языках .
Технология RPC решает эти и некоторые другие проблемы, достигая про-
зрачности путем включения в процесс взаимодействия клиента и сервера спе-
циальных программных компонентов, стабов (stub - заглушка). Взаимодейст-
вие программных компонентов при выполнении удаленного вызова процедуры
иллюстрируется рис. 1. Когда вызываемая процедура действительно является
удаленной , в библиотеку помещается вместо локальной процедуры другая вер -
                                     4
отдельный процесс или виртуальную машину, поэтому, не дожидаясь оконча-
ния работы предыдущих запросов, сразу же может принимать следующие.
     Протокол RPC может использовать несколько различных транспортных
протоколов. В обязанности RPC-протокола входит только обеспечение стан-
дартов и интерпретация передачи сообщений. Достоверность и надежность пе-
редачи сообщений целиком обеспечивается транспортным уровнем. Однако
RPC может контролировать выбор и некоторые функции транспортного прото-
кола. RPC никогда не дублирует функции транспортных протоколов. Если, на-
пример, RPC работает поверх TCP, все заботы о надежности и достоверности
соединения RPC возлагает на TCP. Если протокол RPC установлен поверх UDP,
он может обеспечивать дополнительные собственные функции обеспечения га-
рантированной доставки сообщений.
     Идея, положенная в основу RPC, состоит в том, чтобы сделать вызов уда-
ленной процедуры выглядящим по возможности так же, как и вызов локальной
процедуры. Другими словами – сделать RPC прозрачным: вызывающей проце-
дуре не требуется знать, что вызываемая процедура находится на другой маши-
не, и наоборот. Реализация удаленных вызовов существенно сложнее реализа-
ции вызовов локальных процедур. Начнем с того, что поскольку вызывающая и
вызываемая процедуры выполняются на разных машинах, то они имеют разные
адресные пространства, и это создает проблемы при передаче параметров и ре-
зультатов, особенно если машины не идентичны. Так как RPC не может рассчи-
тывать на разделяемую память, то это означает, что параметры RPC не должны
содержать указателей на ячейки нестековой памяти и что значения параметров
должны копироваться с одного компьютера на другой. Следующим отличием
RPC от локального вызова является то, что он обязательно использует нижеле-
жащую систему связи, однако это не должно быть явно видно ни в определении
процедур, ни в самих процедурах. Удаленность вносит дополнительные про-
блемы. Выполнение вызывающей программы и вызываемой локальной проце-
дуры в одной машине реализуется в рамках единого процесса. Но в реализации
RPC участвуют как минимум два процесса – по одному в каждой машине. В
случае аварийного завершения какого-либо из них могут возникнуть следую-
щие ситуации: при аварии вызывающей процедуры, удаленно вызванные про-
цедуры станут «осиротевшими», а при аварийном завершении удаленных про-
цедур станут «обездоленными родителями» вызывающие процедуры, которые
будут безрезультатно ожидать ответа от удаленных процедур. Кроме того, су-
ществует ряд проблем, связанных с неоднородностью языков программирова-
ния и операционных сред: структуры данных и структуры вызова процедур,
поддерживаемые в каком-либо одном языке программирования, не поддержи-
ваются точно так же во всех других языках.
     Технология RPC решает эти и некоторые другие проблемы, достигая про-
зрачности путем включения в процесс взаимодействия клиента и сервера спе-
циальных программных компонентов, стабов (stub - заглушка). Взаимодейст-
вие программных компонентов при выполнении удаленного вызова процедуры
иллюстрируется рис. 1. Когда вызываемая процедура действительно является
удаленной, в библиотеку помещается вместо локальной процедуры другая вер-