ВУЗ:
Составители:
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. Когда вызываемая процедура действительно является удаленной, в библиотеку помещается вместо локальной процедуры другая вер-
Страницы
- « первая
- ‹ предыдущая
- …
- 2
- 3
- 4
- 5
- 6
- …
- следующая ›
- последняя »