Сетевое ПО Лекция 2 (1061283), страница 2
Текст из файла (страница 2)
Опрос (polling). Этот метод предусматривает наличие еще одного базовогопримитива test (проверить), с помощью которого процесс-получательможет анализировать состояние буфера.2. Прерывание (interrupt). Этот метод использует программное прерываниедля уведомления процесса-получателя о том, что сообщение помещено вбуфер. Хотя такой метод и очень эффективен (он исключает многократныепроверки состояния буфера), у него имеется существенный недостаток усложненноепрограммирование,связанноеспрерываниямипользовательского уровня, то есть прерываниями, по которым вызываются6Сетевое ПО.
Лекция 2(2014г.)(Механизмы межпроцессноговзаимодействия(Inter-Process Communication, IPC) в сети.)процедуры пользовательского режима.Если при взаимодействии двух процессов оба примитива — send и receive —являются блокирующими, говорят, что процессы взаимодействуют по сетисинхронно(рис.2.1),впротивномслучаевзаимодействиесчитаетсяасинхронным (рис. 2.2).Синхронное является более простым, его легко реализовать. Оно такжеболее надежно, так как гарантирует процессу-отправителю, возобновившемусвое выполнение, что его сообщение было получено.
Главный недостаток ограниченный параллелизм и возможность возникновения клинчей.Обычно в ОС имеется один из двух видов примитивов, но ОС являетсяболее гибкой, если поддерживает как блокирующие, так и неблокирующиепримитивы.5 Буферизация при передачи сообщенийПри передаче сообщений могут возникнуть ситуации, когда принимающийпроцесс оказывается не готовым обработать сообщение при его прибытии, нодля процесса было бы желательным, чтобы операционная система на времясохранила поступившее сообщение в буфере для последующей обработки.Способ буферизации зависит от способа синхронизации процессов приобмене сообщениями.5.1 Буферизация при синхронном взаимодействие процессовПри использовании синхронных, то есть блокирующих примитивов,можно вообще обойтись без буферизации сообщений операционной системой.При этом возможны два варианта организации работы примитивов. В первом случае процесс-отправитель подготавливает сообщение всвоей памяти и обращается к примитиву send, после чего процессблокируется. ОС отправителя ждет, когда процесс-получатель выполнит на своемкомпьютере примитив receive, в результате чего ОС получателянаправитслужебноесообщение-подтверждениеготовностикСетевое ПО.
Лекция 2(2014г.)(Механизмы межпроцессноговзаимодействия(Inter-Process Communication, IPC) в сети.)приему основного сообщения. После полученияподтвержденияОСнакомпьютере-отправителе7такогоразблокируетпроцесс-отправитель и тот немедленно после этого пошлетсообщение по сети. Процесс-получатель после обращения кпримитиву receive также переводится своей ОС в состояниеожидания, из которого он выходит при поступлении сообщения посети. Сообщение немедленно копируется ОС в память процессаполучателя, не требуя буферизации, так как процесс ожидает егоприхода и готов к его обработке. Буферизация не требуется и при другом варианте обменасообщениями, когда процесс-отправитель посылает сообщение всеть, не дожидаясь прихода от получателя подтверждения оготовности к приему.
Затем процесс-отправитель блокируется либодо прихода такого подтверждения (в этом случае никакойдополнительной работы с данным сообщением не выполняется),либодоистечениятайм-аута,послекоторогосообщениепосылается вновь, причем в случае многократных повторныхнеудачных попыток сообщение отбрасывается.В обоих случаях сообщение непосредственно из памяти процессаотправителя попадает в сеть, а после прихода из сети - в память процессаполучателя, минуя буфер, поддерживаемый системой.Однако такая организация на практике в сетевых ОС не применяется, таккак в первом варианте процесс-получатель может достаточно долго ждать, покасообщение будет передано по сети (в большой сети, например в Интернете,задержки могут достигать нескольких секунд), а во втором - из-за неготовностипроцесса-получателя, сообщение может многократно бесполезно передаватьсяпо сети, засоряя каналы связи).Поэтомуприиспользованиисинхронныхпримитивоввсежепредусматривают буферизацию.
При этом буфер, как правило, выбирается8Сетевое ПО. Лекция 2(2014г.)(Механизмы межпроцессноговзаимодействия(Inter-Process Communication, IPC) в сети.)размером в одно сообщение, так как процесс-отправитель не может послатьследующее сообщение, не получив подтверждения о приеме предыдущего.Сообщение помещается в буфер, поддерживаемый операционнойсистемой компьютера-получателя, если в момент его прихода процессполучатель не может обработать сообщение немедленно, например из-за того,что процесс либо не является текущим, либо не готов к приему сообщения, таккак не обратился к примитиву receive.Буфер может располагаться как в системной области памяти, так и вобласти памяти пользовательского процесса, в любом случае буферомуправляет операционная система, модули которой получают сообщения посети.5.2 Буферизация при асинхронном взаимодействие процессовДля всех вариантов обмена сообщениями с помощью асинхронныхпримитивов необходима буферизация.Поскольку при асинхронном обмене процесс-отправитель может посылатьсообщение всегда, когда ему это требуется, не дожидаясь подтверждения отпроцесса-получателя, для исключения потерь сообщений требуется буфернеограниченной длины.Так как буфер в реальной системе всегда имеет ограниченный размер, томогут возникать ситуации с переполнением буфера и на них нужно каким-тообразом реагировать.Для уменьшения вероятности потерь сообщений степень асинхронностипроцесса обмена сообщениями обычно ограничивается механизмомуправления потоком сообщений.Управление потоком заключается в том, что при заполнении буфера напринимающей стороне до некоторого опасного порога процесс-передатчикблокируется до тех пор, пока процесс-приемник не обработает часть принятыхсообщений и не разгрузит буфер до безопасной величины.
Конечно,вероятность потерь сообщений из-за переполнения буфера все равно9Сетевое ПО. Лекция 2(2014г.)(Механизмы межпроцессноговзаимодействия(Inter-Process Communication, IPC) в сети.)сохраняется, например из-за того, что служебное сообщение о необходимостиприостановки передачи сообщений может быть потеряно сетью.Асинхронный обмен с управлением потоком - это наиболее сложныйспособорганизацииобменасообщениями,таккакдляповышенияэффективности( максимизации скорости обмена и минимизации потерь), онтребует применения сложных алгоритмов приостановки и возобновленияпроцесс передачи, например таких, которые применяются в протоколе TCP.Операционнаясистемапредоставляетдляприкладныхпроцессовспециальный примитив для создания буферов сообщений.Такого рода примитив, например, create_buffer (создать буфер), процессдолжен использовать перед тем, как отправлять или получать сообщения спомощью примитивов send и receive.
При создании буфера его размер можетлибо устанавливаться по умолчанию, либо выбираться прикладным процессом.Часто такой буфер носит название порта (port), или почтового ящика(mailbox).При реализации схем буферизации сообщений необходимо также решитьвопрос о том, что должна делать операционная система с поступившимисообщениями, для которых буфер не создан.Такая ситуация может возникнуть в том случае, когда примитив sendпроцессом-передатчиком выполнен раньше, чем примитив create_bufferпроцессом-получателем.Каким образом ОС получателя сможет узнать, какому процессуадресовано вновь поступившее сообщение, если имеется несколькоактивных процессов? И как оно узнает, куда его скопировать? Один из вариантов - просто отказаться от сообщения в расчете нато, что отправитель после тайм-аута передаст сообщение повторно ик этому времени получатель уже создаст буфер. Этот подход несложен в реализации, но, к сожалению, отправитель (или скорееядро его компьютера) может сделать несколько таких безуспешных10Сетевое ПО.
Лекция 2(2014г.)(Механизмы межпроцессноговзаимодействия(Inter-Process Communication, IPC) в сети.)попыток. Еще хуже то, что после достаточно большого числабезуспешныхпопытокядроотправителяможетсделатьнеправильный вывод об аварии на машине получателя или онеправильности его адреса. Второй подход к этой проблеме заключается в том, чтобы хранитьхотя бы некоторое время поступающие сообщения в ядре ОСполучателяврасчетенато,чтовскоребудетвыполненсоответствующий примитив create_buffer. Каждый раз, когдапоступает такое «неожидаемое» сообщение, включается таймер.Еслизаданныйвременнойинтервалистекаетраньше,чемпроисходит создание буфера, то сообщение теряется.