Как показано на рис.1, подтверждение приема при вызове удаленной процедуры с использованием сетевого интерфейса пользовательского уровня происходит гораздо быстрее по сравнению с выполнением аналогичной локальной операции в среде Windows NT. Обработка удаленного вызова производится средствами распределенной компонентной объектной модели Microsoft DCOM и архитектуры VIA интерфейса GNN1000. В случае локального вызова используется компонентная объектная модель COM. Кроме того, на рисунке показана задержка подтверждения приема «сырых» сообщений, проходящих через виртуальный интерфейс (это значение принимается за базовый показатель при оценке накладных расходов протокола DCOM). Малое время задержки имеет очень важное значение для построения кластерных систем корпоративного уровня, которые должны обладать высокой готовностью и масштабируемостью. Система управления кластерами и кластерные серверные приложения опираются на специальный протокол циклического опроса, который позволяет восстановить состояние системы в случае возникновения ошибок. Протокол обслуживает переменное число «участников», должен получать ответ в каждом цикле опроса и крайне чувствителен к любой задержке. Кластерные приложения предъявляют высокие требования к надежности (в частности, при выполнении операций резервного копирования и тиражирования) и используют специальные средства межузлового взаимодействия для синхронизации процессов передачи данных между отдельными компонентами системы. Кластерные приложения допускают возможность масштабирования только в том случае, если скорость межузлового взаимодействия во много раз превышает скорость ответа системы на запросы клиентов. Эксперименты с сервером Microsoft Cluster Server, показали, что если малого времени задержки при организации межкластерного взаимодействия добиться не удается, масштабируемость ограничивается восемью узлами [3]. Для приложений, требующих интенсивной обработки, многие специалисты предлагают использовать сети рабочих станций. Однако написание программ для таких сетей представляет собой слишком сложную задачу. Кроме того, для повышения эффективности подобных архитектур, необходимо уменьшить затраты на организацию взаимодействия локальных сетей. Высокая пропускная способность для коротких сообщенийРост потребности в высокой пропускной способности при пересылке коротких сообщений (их размеры, как правило, не превышают 1 Кбайт) обусловлен теми же самыми причинами, что и увеличение спроса на коммуникационные технологии, позволяющие добиться малого времени задержки. Web-серверы, например, очень часто получают и пересылают множество небольших сообщений сразу нескольким пользователям. Уменьшив размер сообщения, передаваемого с максимальной скоростью, можно воспользоваться стандартными протоколами потоков данных (таких, как TCP). Требования этих протоколов к размеру буфера прямо пропорциональны задержке связи. Размер окна TCP, к примеру, зависит от пропускной способности сети. Один из способов обеспечить максимальную пропускную способность при минимальных затратах состоит в том, чтобы попытаться добиться наименьшей задержки в локальных сетях, сохранив при этом приемлемые размеры буфера. Гибкие коммуникационные протоколыТрадиционный барьер между приложениями и протоколами затрудняет разработку более эффективных сетевых прикладных систем. Во главу угла ставятся два вопроса: интеграция приложений со средствами управления буфером протокола и оптимизация маршрута. В обычных системах недостаточность средств управления интегрированным буфером влечет за собой слишком большие накладные расходы при обработке информации. Без рационального управления буфером не удастся снизить расходы на обслуживание пересылок информации между приложением и ядром. Существует несколько способов построения гибких и эффективных коммуникационных протоколов. Можно воспользоваться экспериментальными или оптимизированными версиями традиционных протоколов для интеграции универсальных механизмов с протоколами, разработанными для конкретных приложений. Перспективная технология проектирования протоколов подразумевает управление кадрами на уровне приложений. При этом система буферизации полностью интегрируется со средствами обработки, специфическими для конкретных приложений; при этом многие уровни протоколов оказываются невостребованными и подменяются высокоэффективным, монолитным маршрутом передачи. Можно также задействовать специальный компилятор для трансляции протоколов. Наконец, известны технологии (например, генерация быстрого маршрута в коммуникационной системе Ensemble), основанные на формальных средствах для автоматического создания оптимизированного стека протокола. Эта технология основана на управлении полным стеком протоколов, в том числе и его самыми нижними уровнями, и требует, чтобы стек функционировал в общем адресном пространстве. Основные этапы разработки интерфейсаСетевые интерфейсы пользовательского уровня, базирующиеся на сообщениях, позволяют приложениям обмениваться данными за счет явной пересылки и приема сообщений. Они похожи на привычные интерфейсы передачи сообщений между несколькими компьютерами (такие, как MPI, Intel NX и Thinking Machines CMDD). Все сетевые интерфейсы пользовательского уровня, о которых идет речь, предоставляют возможность одновременного обращения к сети сразу нескольким пользователям. Для обеспечения нужной степени защиты процедуры настройки в них отделены от непосредственной передачи данных. В процессе настройки принимает участие и операционная система. Она отвечает за защиту и исключает взаимное влияние приложений друг на друга. При передаче же данных интерфейсы в обход операционной системы выполняют лишь простые проверки, обеспечивающие необходимый уровень защиты. 18.03.1999г Также в разделе:
|
СодержаниеОткрытые системы
Разное Эта рубрика в архиве
Список номеров за
|
||||||||||||||||||