Операционная система UNIX
Шрифт:
В рассмотренном примере большая часть исходного текста посвящена созданию транспортных узлов и установлению соединения, в то время как завершение сеанса связи представлено скупыми вызовами t_close(3N). На самом деле, вызов t_close(3N) приводит к немедленному разрыву соединения, запрещая дальнейшую передачу или прием данных. Однако виртуальный канал, обслуживаемый протоколом TCP, является полнодуплексным и, как было показано, TCP предусматривает односторонний разрыв связи, позволяя другой стороне продолжать передачу данных. Действиям, предписываемым TCP, больше соответствуют две функции t_sndrel(3N) и t_rcvrel(3N), которые обеспечивают "корректное "прекращение связи (orderly release). Разумеется, эти рассуждения справедливы лишь для транспортного протокола, обеспечивающего передачу данных с предварительным установлением связи, каковым, в частности, является протокол TCP.
Функции t_sndrel(3N) и t_rcvrel(3N) имеют вид:
Вызывая функцию t_sndrel(3N), процесс отправляет другой стороне уведомление об одностороннем прекращении связи, это означает, что процесс не намерен больше передавать данные. В то же время процесс может принимать данные — файловый дескриптор
Другая сторона подтверждает получение уведомления вызовом функции t_rcvrel(3N). Однако поскольку получение такого уведомления носит асинхронный характер, процесс должен каким-то образом узнать, что запрос поступил. Такой индикацией является завершение с ошибкой попытки получения данных от удаленного узла, например, с помощью функции t_rcv(3N). В этом случае вызов функции t_rcv(3N) завершится с ошибкой
Эта ошибка свидетельствует, что произошло событие, связанное с коммуникационным узлом, анализ которого позволяет получить дополнительную информацию о причине неудачи. Текущее событие может быть получено с помощью функции t_look(3N):
Функция возвращает идентификатор, соответствующий одному из событий, перечисленных в табл. 6.6.
Таблица 6.6. События, связанные с коммуникационным узлом
Событие | Значение |
---|---|
T_CONNECT | Узлом получено подтверждение создания соединения |
T_DISCONNECT | Узлом получен запрос на разрыв соединения |
T_DATA | Узлом получены данные |
T_EXDATA | Узлом получены экстренные данные |
T_LISTEN | Узлом получен запрос на установление соединения |
T_ORDREL | Узлом получен запрос на корректное прекращение связи |
T_ERROR | Свидетельствует о фатальной ошибке |
T_UDERR | Свидетельствует об ошибке датаграммы |
Если в рассматриваемом случае событием, связанным с ошибкой t_rcv(3N), является
Проиллюстрируем описанную процедуру фрагментом программы, обрабатывающей корректное прекращение связи:
Программный интерфейс высокого уровня.
Удаленный вызов процедур
В предыдущих разделах рассматривался программный интерфейс достаточно низкого уровня — по существу программа взаимодействовала непосредственно с транспортным протоколом, самостоятельно реализуя некоторый протокол верхнего уровня при обмене данными. В приведенных примерах легко заметить, что значительная часть кода этих программ посвящена созданию коммуникационных узлов, установлению и завершению связи.
С точки зрения разработчика программного обеспечения, более перспективным является подход, когда используется прикладной программный интерфейс более высокого уровня, изолирующий программу от специфики сетевого взаимодействия. В данном разделе мы рассмотрим один из таких подходов, на базе которого, в частности, разработана файловая система NFS, получивший название удаленный вызов процедур (Remote Procedure Call, RPC).
Использование подпрограмм в программе — традиционный способ структурировать задачу, сделать ее более ясной. Наиболее часто используемые подпрограммы собираются в библиотеки, где могут использоваться различными программами. В данном случае речь идет о локальном (местном) вызове, т.е. и вызывающий, и вызываемый объекты работают в рамках одной программы на одном компьютере.