В настоящее время разработка любой сетевой архитектуры в общем случае отталкивается от эталонной модели взаимодействия открытых систем МОС. Однако очевидно, что применительно к задачам создания распределенных систем на основе локальных сетей мини и персональных ЭВМ необходимо модифицировать сетевую архитектуру в сторону ее большей гибкости, улучшения пользовательского интерфейса и уменьшения избыточности ряда функций модели МОС.

В работе рассматривается 4уровневая сетевая архитектура распределенных информационно-вычислительных систем (РИВС), предоставляющая более гибкий транспортный сервис (службу виртуальных каналов и дейтаграммную службу) и обеспечивающая унифицированный интерфейс пользователя к услугам сети по сравнению с моделью МОС. В работе также обсуждаются основные вопросы реализации этой архитектуры в операционной среде ИНМОС.

В контексте данной работы под РИВС понимается совокупность аппаратно-программных средств, реализующих на основе сетей мини и персональных ЭВМ единую (с точки зрения пользователя) систему, в которой распределенная природа ее ресурсов не доставляет пользователю дополнительных затруднений в их использовании. Работа не ориентируется на конкретную аппаратуру локальной сети, ее топологию и методы доступа к передающей среде. Однако подразумевается, что локальная сеть обладает высокой надежностью, реактивностью и пропускной способностью.

Рассмотрим упрощенную модель РИВС: «процесс-заказчик, объект-исполнитель», т. е. она моделируется совокупностью процессов-заказчиков и объектов-исполнителей, выполняющих те или иные операции для процесса-заказчика (например, работа с файлами, базами данных, вычисление спецфункций и т. п.). Эта модель приводит к широкому спектру сообщений, возможных между заказчиком и исполнителем. Сообщения различаются как по семантике и объему передаваемой информации, так и по требованиям к задержке в передаче сообщений, надежности их доставки, временной упорядоченности, уведомлении о потере сообщений и т. п. Исследуем на базе нашей модели основные механизмы межпроцессного обмена и синхронизации с точки зрения их эффективности в предоставлении транспортного сервиса.

Базовой формой взаимодействия заказчик-исполнитель является асинхронное взаимодействие: заказчик, выполнив операцию «послать сообщение», не ждет подтверждения о его приеме исполнителем, а продолжает выполнение своих дальнейших действий. Поскольку обмен сообщениями не синхронизирован, то для его реализации требуется большой буфер памяти для сглаживания флюктуации в обмене сообщениями. Этот вид взаимодействия обеспечивает высокую параллельность в выполнении действий и является основой для передачи небольших объемов служебной информации (например, установление или разъединение виртуального соединения) и организации дейтаграммной транспортной службы, от которой требуется повышенная скорость, но не повышенная надежность.