Варианты архитектуры клиент-сервер

Содержание:

Введение

Данная работа описывает различные варианты и типы архитектур взаимодействия компьютеров по модели клиент-сервер. Эта тема взята из-за возрастающей популярности построения программ, систем и сервисов, основанных на модели клиент – сервер. А возрастает эта тенденция вслед возрастающему количеству видов и массы устройств на самых различных платформах и операционных системах. Гораздо проще создать некий сервис, размещенный на сервере, и сделать 1 клиент для миллионов однотипных устройств, нежели создавать систему управления допуском для каждого.

Развитию технологий основанных на модели клиент – сервер так же способствуют крупнейшие разработчики сетевого и серверного оборудования, а так же ведущие софтверные компании. Если проследить тенденцию последних предложений таких гигантов как HP, Dell, IBM, Microsoft, Oracle, их предложения направлены на расширение возможностей виртуализации, удаленного доступа к ресурсам и управлению.

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

Именно поэтому описание основных вариантов архитектур модели клиент-сервер выбрано в качестве темы курсовой работы.

История развития технологии клиент-сервер

Из истории появления и развития компьютеров, технологий, программирования и вычислительных систем в целом известно, что первые компьютеры разрабатывались без какой либо стандартизации и связи друг с другом.

Несмотря на то, что компаний – производителей на заре компьютерных технологий было крайне мало, полное отсутствие стандартизации и применение собственных разработок делало невозможном общение между компьютерами. Даже программу, написанную для одного компьютера невозможно было запустить на другом компьютере другого производителя.

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

Мэйнфрейм

Тогда было предложено первое решение, которое стало основой для модели клиент-сервер. Большой и мощный компьютер, выполняющий вычисления для нескольких простых и «слабеньких» компьютеров предприятия или отделов - мэйнфрейм.

Историю мейнфреймов принято отсчитывать с появления в 1964 году универсальной компьютерной системы IBM System/360, на разработку которой корпорация IBM затратила 5 млрд. долларов. Сам термин «мейнфрейм» происходит от названия типовых процессорных стоек этой системы. В 1960-х — начале 1980-х годов System/360 была безоговорочным лидером на рынке. Её клоны выпускались во многих странах, в том числе — в СССР (серия ЕС ЭВМ).

В начале 1990-х начался кризис рынка мейнфреймов, пик которого пришёлся на 1993 год. Многие аналитики заговорили о полном вымирании мейнфреймов, о переходе от централизованной обработки информации к распределённой (с помощью персональных компьютеров, объединённых двухуровневой архитектурой «клиент-сервер»). Многие стали воспринимать мейнфреймы как вчерашний день вычислительной техники, считая Unix- и PC-серверы более современными и перспективными.

Важной причиной резкого уменьшения интереса к мейнфреймам в 1980-х годах было бурное развитие PC и Unix-ориентированных машин, в которых благодаря применению новых технологий создания микросхем удалось значительно уменьшить энергопотребление, а их размеры достигли размеров настольных станций. В то же время для установки мейнфреймов требовались огромные площади, а использование устаревших полупроводниковых технологий в мейнфреймах того времени влекло за собой необходимость жидкостного (например, водяного) охлаждения. Так что, несмотря на их вычислительную мощь, из-за дороговизны и сложности обслуживания мейнфреймы всё меньше пользовались спросом на рынке вычислительных средств.

Ещё один аргумент против мейнфреймов состоял в том, что в них не соблюдается основной принцип открытых систем, а именно — совместимость с другими платформами.

Восприняв критику конструктивно, руководство компании IBM, основного производителя аппаратного и программного обеспечения мейнфреймов, выработало кардинально новую стратегию в отношении этой платформы с целью резко повысить производительность, снизить стоимость владения, а также добиться высокой надёжности и доступности систем. Достижению этих планов способствовали важные перемены в технологической сфере: на смену биполярной технологии изготовления процессоров для мейнфреймов пришла технология КМОП. Переход на новую элементную базу позволил значительно снизить уровень энергопотребления мейнфреймов и упростить требования к системе электропитания и охлаждения (жидкостное охлаждение было заменено воздушным). Мейнфреймы на базе КМОП-микросхем быстро прибавляли в производительности и уменьшались в габаритах. Поворотным же событием стал переход на 64-разрядную архитектуру z/Architecture. Современные мейнфреймы перестали быть закрытой платформой: они способны поддерживать на одной машине сотни серверов с различными операционными системами.

Согласно одному из прогнозов Gartner, к 1993 году ожидалось отключение последнего мейнфрейма, однако по состоянию на 2013 год не только многие мейнфреймы ещё не выведены из продуктивной эксплуатации, но и активно выпускаются новые, и продажи новых машин спорадически растут.

Особенности мейнфреймов последних поколений

Время наработки на отказ современных мейнфреймов оценивается в 12-15 лет. Надёжность мейнфреймов — это результат их почти 60-летнего совершенствования.

Повышенная устойчивость систем. Мейнфреймы могут изолировать и исправлять большинство аппаратных и программных ошибок за счёт использования следующих принципов:

Дублирование: два резервных процессора, резервные модули памяти, альтернативные пути доступа к периферийным устройствам.

Горячая замена всех элементов вплоть до каналов, плат памяти и центральных процессоров.

Целостность данных. В мейнфреймах используется память с коррекцией ошибок. Ошибки не приводят к разрушению данных в памяти, или данных, ожидающих вывода на внешние устройства. Дисковые подсистемы, построенные на основе RAID-массивов с горячей заменой и встроенных средств резервного копирования защищают от потерь данных.

Рабочая нагрузка. Рабочая нагрузка мейнфреймов может составлять 80-95 % от их пиковой производительности. Операционная система мейнфрейма будет обрабатывать всё сразу, причём все приложения будут тесно сотрудничать и использовать общие компоненты ПО.

Пропускная способность. Подсистемы ввода-вывода мейнфреймов разработаны так, чтобы работать в среде с высочайшей рабочей нагрузкой на ввод-вывод данных.

Масштабирование. Масштабирование мейнфреймов может быть как вертикальным, так и горизонтальным. Вертикальное масштабирование обеспечивается линейкой процессоров с производительностью от 5 до 200 MIPS и наращиванием до 12 центральных процессоров в одном компьютере. Горизонтальное масштабирование реализуется объединением ЭВМ в многомашинный кластер, выглядящий с точки зрения пользователя единым компьютером. Всего можно объединить до 32 машин.

Программное масштабирование — на одном мейнфрейме может быть сконфигурировано фактически бесконечное число различных серверов. Причем все серверы могут быть изолированы друг от друга так, как будто они выполняются на отдельных выделенных компьютерах и в то же время совместно использовать аппаратные и программные ресурсы и данные.

Доступ к данным. Поскольку данные хранятся на одном сервере, прикладные программы не нуждаются в сборе исходной информации из множества источников, не требуется дополнительное дисковое пространство для их временного хранения, не возникают сомнения в их актуальности. Требуется небольшое количество физических серверов и значительно более простое программное обеспечение. Всё это, в совокупности, ведёт к повышению скорости и эффективности обработки.

Защита. Встроенные в аппаратуру возможности защиты, такие как криптографические устройства, и Logical Partition, и средства защиты операционных систем, дополненные программными продуктами RACF или VM:SECURE, обеспечивают надёжную защиту.

Пользовательский интерфейс. Пользовательский интерфейс у мейнфреймов всегда оставался наиболее слабым местом. Сейчас же стало возможно для прикладных программ мейнфреймов в кратчайшие сроки и при минимальных затратах обеспечить современный веб-интерфейс.

Положение на рынке

Сегодня использование мейнфреймов даже для крупнейших компаний мира, стало крайне накладным, по сравнению с имеющимися альтернативами. И если многие средние и крупные фирмы уже давно перешли на вычислительные возможности мощных современных серверов, то на текущий момент крупнейшие корпорации мира и исследовательские институты так же подходят к этому решению. Так NASA отключило последний из своих мейнфреймов 12 февраля 2012 года.^[1]

Суперкомпьютеры

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

Суперкомпьютеры используются для научных и инженерных задач (высокопроизводительные вычисления, например, в области метеорологии или моделирования ядерных процессов), где ограничительными факторами являются мощность процессора и объём оперативной памяти, тогда как мейнфреймы применяются для целочисленных операций, требовательных к скорости обмена данными, к надёжности и к способности одновременной обработки транзакций (ERP, системы онлайн - бронирования, автоматизированные банковские системы). Производительность мейнфреймов, как правило, вычисляется в миллионах операций в секунду (MIPS), а суперкомпьютеров — в операциях с плавающей запятой (точкой) в секунду (FLOPS).

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

Развитие технологии клиент сервер.

Идея организовать вычислительные ресурсы в соответствии с архитектурой клиент-сервер возникла на уровне рабочих групп и подразделений компаний. Руководители рабочих групп в компаниях и структурных подразделениях пришли к пониманию того что мэйнфрейм это хорошо но уже не так оперативно как того требует возрастающая скорость бизнеса.

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

Но сеть только персональных компьютеров, так и сугубо одноранговая сеть в принципе не смогли существовать в масштабе предприятия. Необходимо было определить стандарты, форматы, базы и уровень доступа в каждой группе, отделе, предприятии.

Решить эти вопросы помогла единая система управления ресурсами и предоставляющая доступ с разграничением прав и полномочий среди клиентов. Клиент серверный вариант работы с Информационной системой предприятия стал корпоративным стандартом и полностью управлялся ИТ отделом корпорации.

Предпосылки развития клиент-серверных решений.

В современном мире архитектура клиент- сервер является наиболее выгодной и привлекательной для бизнеса. Причина этому одна, но очень существенная – стоимость оборудования и рабочего места для сотрудника. Рассмотрим подробнее этот момент.

При установке мощных рабочих станций работодатель должен затратить большие ресурсы на

- приобретение дорогостоящего оборудования и софта.

- нанять специалистов, постоянно поддерживающих парк этой техники.

- обеспечить площадь под работника и оборудование при постоянно растущей стоимости арендных площадей.

- обеспечить условия труда согласно санитарным нормам, складской, бухгалтерский отчет и другие производственные расходы.

И это далеко не полный список затрат владельца бизнеса. И на протяжении последних 10 лет бизнес, так или иначе, увеличивает запрос к решениям, построенным на модели клиент-сервер.

Самыми популярными для бизнеса сегодня являются такие стратегии и тенденции как:

BYOD

BYOD – Bring your own device (принеси свое оборудование) – одна из популярнейших концепций на Западе. Идея экономии для компании проста как карандаш – каждый сотрудник приходит на работу со своим ноутбуком, на котором уже установлен его софт и настроено именно на этого работника, кроме того сам работник обеспечивает обслуживание этого устройства. Это экономит работодателю минимум 100$ на человека единомоментно, если в его работе используются простые и бесплатные приложения и недорогой ноутбук.

Для совместной работы на предприятии, доступа к периферийным устройствам, CRM и прочему используются клиенты для доступа к ресурсам внутри компании. При этом не столь важно находится ли сотрудник в офисе или вне офиса, при установлении подключения (опять же по технологии клиент сервер), ему будут доступны все необходимые ресурсы компании.

Облачные решения.

Облачные решения – это не просто совокупность решений и технологий, построенных по модели клиент –сервер. Сегодня облачные решения – это маркетинговый тренд и основная ориентация крупнейших провайдеров и IT компаний.

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

Суть в том, что облачные решения – это квинтэссенция модели клиент – сервер. В данном сегменте представлены почти все виды возможных программ, услуг, сервисов, типы серверов, приложений. Чего только не реализовано в облаке:

- Вычисления. Сложные расчеты для биологии, астрофизики, атомного взаимодействия, медицины и других отраслей.

- Приложения. Офисные, архитектурные, дизайнерские, бухгалтерские, прикладные программы.

- Замена «железа». Телефония, файловое хранилище, почтовые сервисы, CRM, видеоконференции, удаленное управление оборудованием и другие типы замещения физического оборудования «облачными» аналогами.

- Облако под ключ. Нестандартные задачи легко реализуются «проектными специалистами» под задачи заказчика. Это быстрее и намного выгоднее для бизнеса, особенно если речь идет о краткосрочной или среднесрочной перспективе.

Плюсы модели клиент-сервер на предприятии.

Снижение стоимости оборудования.

Современный мир – это мир предпринимателей, мир бизнеса. Главная задача бизнеса – получение прибыли и одно из основных направлений ее увеличения – снижение затрат. Таким образом, снижение стоимости оборудования – одна из основных причин развития архитектуры клиент- сервер вообще и появления новых технологий клиент-серверного взаимодействия в частности.

Если предприятие крупное, то покупка дорогостоящего серверного оборудования в любом будет иметь место. Однако при построении большинства сервисов и программ по модели клиент сервер, предприятие может существенно снизить стоимость компьютерного оборудования, с которого запускаются клиенты.

Так, например многие крупные компании для организации работы определенных отделов используют маломощные энергоэффективные бездисковые компьютеры-клиенты – «тонкие клиенты».

Тонкий клиент (англ. thin client) в компьютерных технологиях — бездисковый компьютер-клиент в сетях с клиент-серверной или терминальной архитектурой, который переносит все или большую часть задач по обработке информации на сервер. В целом такой клиент может быть не только куплен, но и собран из компьютерного железа 10-15летней давности. Российские ИТ специалисты оценивают высокую устойчивость к отказам у тонких клиентов, если они находятся в нормальных условиях эксплуатации.

Широко распространенный в России пример – программа 1С. Последняя ее версия весьма требовательна к ресурсам, а обычной практикой в крупных компаниях является размещение 1С на специальном, выделенном только под нее сервере.

Снижение совокупной стоимости софта

Кроме удешевления самого оборудования, снижается цена софта. Софт для бездисковой загрузки используется в основном бесплатный (GNU GPL, Apache и др.). Несмотря на это, все же приходится оплачивать терминальные лицензии, но, как правило, софтверные компании предлагают на них особые условия приобретения. К тому же, как правило, количество именно одновременно используемых при подключении к серверу лицензий будет меньше в сравнении с обычными лицензиями.

Например, в архитектурно – строительной компании есть мощный CAD софт, работающий на сервере. В CAD программе постоянно работает 5 инженеров и раз в день для проверки и печати чертежей программой пользуются 3 человека и 1 человек с удаленной станции. Для лицензирования обычной версии ПО потребовалось бы 9 недешевых лицензий. При этом для клиент-серверного варианта – можно было бы обойтись 6-7 лицензиями. Существенная экономия на лицензиях, так как пример затрагивает всего лишь 1 отдел. Это огромная экономия в Масштабах предприятия.

Снижение стоимости обслуживания. При наличии правильно настроенных один раз клиентов, администрировать нужно будет только сервера.

Заранее определенный порядок допуска к ресурсам.

В экономике давно известно, а на практике (особенно Российской) доказано то, что при увеличении масштабов предприятия пропорционально возрастает и сложность взаимодействия при согласовании, принятии решений между различными подразделениями и рабочими группами. При наличии филиальных сетей и групп компаний, проблема становится более значимой.

При этом зачастую для работы одних подразделений требуются результаты, обработанные или полученные в процессе работы другой группы. При этом даже готовые и обработанные данные зачастую могут просто храниться на локальных дисках сотрудников рабочей группы. При этом решение о передаче готового результата – как правило, прерогатива руководителя рабочей группы.

При работе в системе клиент –сервер, обработанные данные при сохранении уже находятся на сервере. При этом на этапе планирования информационной системы заранее определено, какой отдел и в каком объеме сможет получить результат этой работы. Так к примеру бухгалтер на участке зарплаты может рассчитывать зарплату сотруднику сразу после того как руководитель его группы подтвердил закрытие его последней из плановых работ за месяц, а директор предприятия увидел общий прогресс выполнения плана.

Независимость от платформы.

В последнее время не столь актуальный пункт, так как производители выпускают оборудование с минимальным использованием проприетарных архитектур и интерфейсов. То есть все современное оборудование одного производителя может «общаться» с оборудованием другого производителя. Однако коллизии и несовместимость и сейчас не редкость.

Недостатки клиент-сервера при использовании на предприятии

Усложнение и удорожание администрирования систем.

При переходе к технологии клиент-сервер количество единиц оборудования и софта существенно снижается. При этом возрастает качественная сложность работ. Вся нагрузка смещается от клиентских единичных рабочих станций к серверам, что приводит к:

- увеличению сложности работ,

- повышению требований к профессиональным навыкам обслуживающего персонала

- повышению ответственности обслуживающего персонала.

Повышенные требования к отказоустойчивости

Если при работе на локальном компьютере, он отказывал, то простаивало только 1 рабочее место. При этом клиент серверной модели работы оборудования на предприятии при поломке сервера или повреждении сетевой инфраструктуры может быть парализована работа всего предприятия или крупная его часть.

При отказе локального компьютера такое рабочее место восстановить можно в течении часа-двух без наличия резервных копий, с резервными копиями – от 5 минут.

При отказе сервера для его восстановления может потребоваться не один день. Это огромные издержки даже для средних компаний (от 500 человек), убытки могут исчисляться десятками или даже сотнями тысяч долларов в сутки. Для крупнейших международных компаний такая ситуация – это крах.

Конечно же, во всех средних и крупных компаниях используется резервирование, но к резервированию оборудования в системах клиент-сервер предъявлены повышенные требования.

Оборудование должно резервироваться минимум по системе N+1^[2]. При этом стоит понимать, что приобретение серверного оборудования на порядок затратнее, нежели пользовательского.

Варианты архитектуры клиент-сервер

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

Разделение приложения на отдельные задачи, размещаемые на различных платформах для большей эффективности.

В общем виде это означает, что программа представления данных находится на машине пользователя (на клиенте), а программа управления данными и сами данные — на сервере. В зависимости от приложения и используемого программного обеспечения вся обработка данных может осуществляться на клиентской машине или распределяться между клиентом и сервером. Сервер соединяется со своими клиентами по сети. Серверное программное обеспечение принимает запросы от клиентского программного обеспечения и возвращает ему результаты

Варианты реализации архитектуры клиент-сервер.

Сервер – программно аппаратный комплекс, на котором находятся данные и определенная логика их обработки, а так же устройства передачи обработанного запроса на машины-клиенты в сети.

Совместная с клиентом обработка запросов

клиента сервером и возвращение результатов клиенту. В этой модели обработка данных приложением распределена (не обязательно поровну) между клиентом и сервером. Обработка данных инициируется и частично управляется клиентом, но не в режиме «ведущий-ведомый», а, скорее, в режиме сотрудничества.

Вычислительная модель клиент-сервер

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

Приложение клиент-сервер

Любое приложение, в котором инициатор действия находится в одной системе, а исполнитель действия — в другой. Кроме того, в большинстве приложений клиент-сервер один сервер обслуживает запросы нескольких клиентов

Как предполагает термин, окружение клиент-сервер состоит из клиентов и серверов. Клиентские машины, как правило, представляют собой однопользовательские персональные компьютеры или рабочие станции, предоставляющие конечным пользователям дружественный интерфейс. Клиентская станция обычно имеет наиболее удобный графический интерфейс пользователя, предполагающий наличие окон и мыши. Наиболее известные примеры подобных интерфейсов — интерфейсы операционных систем Microsoft Windows и Macintosh. Клиентские приложения предполагают простоту использования и знакомые инструментальные средства, например, электронные таблицы.

Каждый сервер в окружении клиент-сервер предоставляет клиентам набор услуг. Наиболее распространенным типом сервера в архитектуре клиент-сервер является сервер баз данных, как правило, управляющий реляционной базой данных.

Высокопроизводительный сервер обеспечивает коллективный доступ нескольких клиентов к одной и той же базе данных.

Помимо клиентов и серверов в окружение клиент-сервер входит сеть. Вычислительная модель клиент-сервер по определению является распределенной. Пользователи, приложения и ресурсы располагаются на разных компьютерах и соединены общей локальной, глобальной или составной сетью.

Отличие клиент-сервер от других распределенных решений

Есть несколько характеристик, отличающих вычислительную модель клиент-сервер от обычных схем распределенных вычислений.

1. В приложениях клиент-сервер большое внимание уделяется созданию на клиентской машине дружественного пользователю интерфейса. Таким образом, пользователь получает полный контроль над расписанием и режимом работы компьютера, а менеджеры уровня отделов получают возможность реагировать на локальные проблемы.

2. Хотя приложения являются распределенными, в архитектуре клиент-сервер, как правило, используются централизованные корпоративные базы данных. Это позволяет руководству корпорации сохранять полный контроль над инвестициями в информационные системы, а также обеспечивать полную связность всех систем. В то же время такая конфигурация избавляет различные отделы компании от накладных расходов по управлению сложными вычислительными системами, но позволяет им выбирать типы машин и интерфейсы, которые им необходимы для доступа к данным.

3. Как корпоративные пользователи, так и производители отдают предпочтение открытым и модульным системам. Это означает, что пользователю предоставляется более широкий выбор продуктов и большая свобода в объединении оборудования от различных производителей.

4. Компьютерная сеть является ключевым звеном данной архитектуры. Поэтому вопросы сетевого администрирования и сетевой безопасности при работе с информационными системами данного типа имеют приоритет.

Приложения клиент-сервер

Важнейшей особенностью вычислительной модели клиент-сервер является распределение прикладных задач между клиентами и серверами. На клиенте, так и на сервере базовым программным обеспечением является, разумеется, операционная система.

Одно из преимуществ в данном случае – свобода при выборе платформ и ОС. Для клиента и для сервера они могут быть разными. Например, Самый популярный Web-Server – Apache и Ngnx (и их связка) работают на Linux-based ОС, а клиентом может быть любая платформа. Единственное требование – наличие одинаковых каналов передачи данных (сегодня наиболее популярен Ethernet).^[3]

Взаимодействие клиента и сервера обеспечивается коммуникационным программным обеспечением. Примерами такого программного обеспечения являются стек семиуровневых протоколов TCP/IP,- протоколы модели OSI, а также различные фирменные архитектуры, вроде SNA, так же семиуровневого, но не совпадающего с сетевой моделью OSI.^[4]

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

В некоторых случаях для этого может быть необходимо, чтобы большая часть программного обеспечения выполнялась на сервере, тогда как в других случаях большая часть логики может быть реализована на клиенте.

Наконец, существенным фактором успеха является метод взаимодействия пользователя с системой, то есть большое значение имеет пользовательский интерфейс клиентской машины. В большинстве систем клиент-сервер графическому интерфейсу пользователя (Graphical User Interface, GUI) уделяется очень серьезное внимание — он должен быть простым и удобным, но одновременно мощным и гибким. Таким образом, модуль услуг представления на рабочей станции можно считать ответственным за дружественный интерфейс с распределенными приложениями.

Уровень представления занимается форматированием данных для их корректной интерпретации каждым из двух взаимодействующих компьютеров. Модуль услуг представления имеет дело с взаимодействием пользователя и приложения, а также с функциональностью графического интерфейса пользователя.

Базы данных

Рассмотрим концепцию распределенной между клиентом и сервером логики приложения на примере реляционной базы данных. В этой среде сервер является сервером баз данных. Взаимодействие между клиентом и сервером осуществляется в форме транзакций, в которых клиент посылает серверу запрос и получает ответ на него.

Сервер отвечает за управление базой данных. На клиентских машинах могут располагаться различные приложения, пользующиеся базой данных. Специальное программное обеспечение связывает клиента и сервера, позволяя клиенту выполнять запросы и получать доступ к базе данных. Популярным примером такой логики является язык структурированных запросов (Structured Query Language, SQL).

Вся прикладная логика — программы для обработки и анализа данных — располагается на клиентской стороне, тогда как сервер занимается только управлением базой данных. Приемлемость такой конфигурации зависит от стиля и задачи конкретного приложения.

Предположим, например, что основная цель приложения заключается в обеспечении доступа для поиска записей в режиме подключения (on-line). К примеру, существует сервер с базой данных в 1 000 000 записей. В ней пользователь с клиентской станции хочет сделать выборку и направляет базе уточняющие запросы. При общем запросе сервер возвращает 1000 записей, при уточняющем запросе база выдает 40 записей, а при втором уточнении – всего 1 запись.

Такое приложение является идеальным примером работы клиент-серверной модели.

Для работы базы данных требуется обеспечение бесперебойной работы в любых условиях, жесткий контроль к уровням доступа к ней и особые аппаратные средства. Для быстрой работы с базой данных требуются высокие характеристики ввода/вывода, мощный процессор и внушительные объемы оперативной памяти. Все это лишние затраты для оснащения ими рабочей станции, в силу чего они органичней смотрятся на серверах. При высоких нагрузках память должна быть с коррекцией ошибок. Такие типы памяти не используются в рабочих станциях.

Перемещение 1 000 000 записей по сети в обе стороны весьма затратно даже в современных локальных сетях, где гигабит становится стандартом. Таким образом, серверу недостаточно просто получать доступ к записям от имени клиента. Сервер должен обладать логикой базы данных, позволяющей ему выполнять операции поиска от имени клиента.

Кроме того на сервере должно быть установлено ПО с логикой базы данных, контролироваться доступ и типы допустимых действий и операций, лимиты.

Прикладная реализация клиент-сервер

В рамках общей структуры приложений клиент-сервер выполняемая работа может быть разделена между клиентом и сервером по-разному. Точная доля исполняемых операций и объем передаваемых по сети данных зависят от природы информации, содержащейся в базе данных, поддерживаемых типов приложений, доступности оборудования, которое может работать совместно, а также от характера использования данных в организации.

Схемы некоторых основных вариантов приложений баз данных показаны на рисунке

В целом можно выделить 5 типов обработки запроса от клиента сервером. О них ниже.

Обработка данных на базе хоста. Данная схема не является настоящим приложением клиент-сервер, а относится к традиционному окружению мэйнфрейма, когда вся или практически вся обработка данных осуществляется на главной вычислительной машине. Зачастую в подобной вычислительной среде интерфейс пользователя предоставляет примитивный терминал. Но даже если пользователь сидит за персональным компьютером, роль персонального компьютера в этом случае ограничивается эмуляцией терминала.

Обработка данных на базе сервера. Простейшим классом конфигурации клиент-сервер является схема, в которой клиент отвечает лишь за предоставление графического интерфейса пользователя 1, тогда как практически вся обработка данных осуществляется на сервере.

Обработка данных на базе клиента. Данная схема представляет собой другую крайность. Практически вся обработка данных осуществляется на клиенте, за исключением процедур проверки целостности данных и прочей логики, относящейся к обслуживанию базы данных, которые лучше исполнять на сервере. Как правило, наиболее клиент-сервер сложные функции для работы с базой данных располагаются на клиентской стороне. На сегодняшний день подобная схема, возможно, является наиболее распространенной реализацией архитектуры клиент-сервер.

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

Главное достоинство модели «толстого» клиента заключается в том, что она максимально опирается на вычислительные возможности настольного компьютера, освобождая сервер от излишней нагрузки по обработке данных и, таким образом, повышая их эффективность и снижая вероятность того, что сервер станет узким местом системы.

Однако у стратегии «толстого» клиента имеются и недостатки. Оснащение настольных компьютеров новыми функциями быстро истощает их вычислительные мощности, заставляя компании проводить модернизацию. Если в работу приложения вовлекаются множество пользователей из разных подразделений, компании приходится устанавливать локальную сеть с высокой пропускной способностью для поддержки огромных объемов данных, передаваемых между «тонкими» серверами и «толстыми» клиентами. Наконец, приложения, распределенные по нескольким десяткам и сотням настольных машин, трудно поддерживать, обновлять и заменять.

Архитектура с промежуточным сервером.

Традиционная архитектура клиент-сервер состоит из двух уровней, или звеньев: клиентского и серверного. В последние годы все большее распространение получает трехзвенная архитектура клиент-сервер

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

Такая модель является наиболее предпочтительной и рекомендуема передовыми производителями серверного оборудования и программного обеспечения.

Так, к примеру, для развертывания 1с на предприятии среди рекомендаций дилеров серверного оборудование и специалистов 1С наиболее приемлемой конфигурацией является следующая:

- сервер базы данных

- сервер приложения

- сервер базы данных.

Программное обеспечение промежуточного сервера

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

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

Наиболее общий подход к удовлетворению этих требований заключается в использовании стандартных интерфейсов и протоколов между приложением, с одной стороны, и коммуникационным программным обеспечением и операционной системой, с другой. Эти стандартизованные интерфейсы и протоколы получили название промежуточного программного обеспечения. Наличие стандартных программных интерфейсов облегчает развертывание одного и того же приложения на серверах и рабочих станциях разных типов. Это, очевидно, является достоинством не только для потребителя, но и для производителя. Это связано с тем, что потребители приобретают приложения, а не серверы. Потребители только выбирают серверные продукты, на которых работают нужные им приложения. Стандартизованные протоколы необходимы для взаимодействия различных серверных интерфейсов с клиентами.^[5]

Существуют разные пакеты промежуточного программного обеспечения от очень простых до очень сложных. Всех их объединяет способность скрывать от пользователя сложности и несоответствия различных сетевых протоколов и операционных систем. Производители клиентов и серверов, как правило, предлагают на выбор ряд популярных пакетов промежуточного программного обеспечения. Таким образом, пользователь может выбрать определенную стратегию развертывания промежуточного программного обеспечения, а затем заняться приобретением оборудования от разных производителей, поддерживающих данную стратегию.

Архитектура промежуточного программного обеспечения программного обеспечения в архитектуре клиент-сервер. Точная роль промежуточного программного обеспечения зависит от вычислительной модели клиент-сервер. существует несколько классов приложений клиент-сервер, зависящих от способа разделения функций приложения.

Основное назначение промежуточного программного обеспечения заключается в обеспечении доступа приложения или пользователя к различным услугам, предоставляемым на серверах, причем так, чтобы не беспокоиться о различиях серверов. Стандартным средством доступа к реляционной базе данных как для локального, так и для удаленного пользователя или приложения является язык структурированных запросов (SQL). Однако многие производители реляционных баз данных, хотя и поддерживают язык SQL, добавили к нему свои собственные расширения. Это, с одной стороны, позволяет производителям различать свою продукцию, но, с другой стороны, приводит к несовместимости.^[6]

Для примера рассмотрим распределенную систему, обслуживающую, помимо прочего, отдел кадров. Основные сведения о сотрудниках, такие как имена, адреса и т. д., могли бы храниться в базе данных NOsql, тогда как информация о зарплате — в базе данных от Oracle. Когда пользователь в отделе кадров запрашивает доступ к определенным записям, он не должен думать, в которой из баз данных хранятся требуемые ему записи и кто является производителем этой базы данных.

На роль промежуточного программного обеспечения полезно взглянуть с точки зрения логики, а не реализации. Вся распределенная система может рассматриваться как набор приложений и ресурсов, доступных пользователю. Пользователям не нужно беспокоиться о расположении данных или приложений. Все приложения работают поверх унифицированного прикладного программного интерфейса (Application Programming Interface, API). ^[7]За маршрутизацию запросов клиента к соответствующему серверу отвечает промежуточное программное обеспечение, присутствующее на всех клиентских и серверных платформах.

Пример применения промежуточного программного обеспечения для интеграции несовместимых продуктов иллюстрирует рис. 17.10. В этом случае промежуточное программное обеспечение используется для решения проблем несовместимости сетей и операционных систем. Сети DECnet, Novell и TCP/IP соединены магистральной сетью. Промежуточное программное обеспечение, работающее в каждой сети, гарантирует, что у всех сетевых пользователей будет прозрачный доступ к приложениям и ресурсам во всех трех сетях.

Несмотря на разнообразие предлагаемого на рынке промежуточного программного обеспечения, в основе всех этих продуктов лежит, как правило, один из трех механизмов: передачи сообщений, вызова удаленных процедур и объектно-ориентированный механизм. Мы рассмотрим эти три механизма последовательно.

Передача сообщений

Распределенную передачу сообщений, реализующую функциональность

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

Процессы пользуются услугами модуля передачи сообщений. Запросы на эти услуги могут иметь вид примитивов и параметров. Примитив соответствует исполняемой функции, в параметры используются для передачи данных и контроля над информацией. Конкретная форма примитивов зависит от программного обеспечения передачи сообщений. Это может быть вызов процедуры или передача сообщения процессу

Примитив Send используется процессом, желающим отправить сообщение. Входными параметрами этого примитива являются идентификатор получающего процесса и содержимое сообщения. Модуль передачи сообщений формирует блок данных, включающий эти два элемента. Этот блок данных посылается на машину, на которой работает получающий процесс, при помощи каких-либо сетевых протоколов, например, TCP/IP. Когда адресат получает блок данных, этот блок направляется модулю передачи сообщений. Этот модуль исследует поле идентификатора процесса и сохраняет сообщение в буфере этого процесса.

В этом сценарии получающий процесс должен объявить о своем желании получать сообщения, выделить буфер для сообщений и информировать модуль передачи сообщений при помощи примитива Receive. Альтернативный метод не требует подобного объявления. Просто когда модуль передачи сообщений получает сообщение, он сигнализирует процессу, которому оно адресовано, а затем помещает сообщение в общий буфер.

Существует несколько вариантов реализации механизма распределенной передачи сообщений, о которых будет говориться далее.

Надежная передача сообщений

Надежной называется такая система передачи сообщений, которая гарантирует доставку сообщения, если такая доставка возможна. В подобной системе используется надежный транспортный протокол или сходная логика, а также должны поддерживаться контроль ошибок, квитирование, повторная передача и восстановление порядка следования сообщений. Поскольку доставка гарантирована, нет необходимости уведомлять передающий процесс о доставке сообщения. Тем не менее, может быть полезно возвращать передающему процессу подтверждения, чтобы уведомить его о том, что сообщение доставлено. В любом случае, если системе не удается доставить сообщение (например, из-за неисправности сети или выходе из строя получателя), передающий процесс уведомляется о неудаче. Другую крайность представляет собой система передачи сообщений, которая просто посылает сообщения в компьютерную сеть, но не сообщает ни об успехе, ни о неудаче. Эта альтернатива позволяет значительно упростить систему передачи сообщений и накладные расходы на обработку и взаимодействие. Если приложению требуется подтверждение доставки сообщения, это может быть реализовано на прикладном уровне.

Синхронные и асинхронные системы передачи сообщений

При обращении к асинхронному (также называемому неблокирующим) примитиву, процесс не приостанавливается. Таким образом, после того как процесс вызывает примитив Send, операционная система возвращает процессу управление сразу после установки сообщения в очередь на передачу или после создания копии сообщения. Когда сообщение передано или скопировано в безопасное место для последующей передачи, передающий процесс прерывается и, таким образом, информируется о том, что буфером сообщения можно пользоваться снова. Если копии сообщения не создается, то любые изменения сообщения, производимые передающим процессом уже после обращения к примитиву Send, но до отправки сообщения, являются рискованными. Аналогично, после обращения к асинхронному примитиву Receive процесс продолжает работу. Когда сообщение прибывает, процесс информируется об этом событии путем прерывания или периодического опроса.

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

Альтернатива заключается в использовании синхронных или, как их еще называют, блокирующих примитивов. При вызове синхронного примитива Send управление не возвращается передающему процессу до тех пор, пока сообщение не будет передано (ненадежное обслуживание), или до тех пор, пока не будет получено подтверждение о доставке сообщения (надежное обслуживание). Блокирующий примитив Receive не возвратит управление, пока сообщение не окажется в выделенном для него буфере.

Уделенные вызовы процедур

Концепция вызова удаленных процедур (remote procedure call — RPC) была разработана и реализована в компанией XEROX еще начале 80-х годов XX века. Общий смысл RPC можно представить так: программа может выполнять не только собственные (скомпилированные) процедуры и функции, но и обращаться к процедурам удаленного сервера

Для установки связи, передачи вызова и возврата результата клиентский и серверный процессы обращаются к специальным компонентам – «заглушкам», соответственно клиентской и серверной (client stub и server stub). Эти stub'ы не реализуют никакой прикладной логики и предназначены только для организации взаимодействия удаленных (в общем случае) приложений. Все RPC-обращения клиента (имена функций и списки параметров) упаковываются клиентской заглушкой в сетевые сообщения (этот процесс называется marshaling) и ей же передаются серверной заглушке. Та, в свою очередь, распаковывает полученные данные (unmarshaling), передает их реальной функции сервера, а полученные результаты упаковывает в обратном порядке. Клиентская заглушка принимает ответ, распаковывает его и возвращает в приложение. Таким образом, процедуры-заглушки изолируют прикладные модули клиента и сервера от уровня сетевых коммуникаций.

Для определения правил, задающих отношения между клиентом и сервером RPC, используется язык описания интерфейсов IDL. Интерфейс содержит определение имени функции и полное описание передаваемых параметров и результатов выполнения. Правила IDL обеспечивают независимость механизма RPC от языков программирования: обращаясь к удаленной процедуре, клиент использует свои языковые конструкции, а IDL-компилятор преобразует их в унифицированные описания, понятные серверу. На сервере IDL-описания преобразуются в конструкции языка программирования, на котором реализован серверный процесс.

У RPC как средства организации сетевого взаимодействия есть ряд минусов, кроющихся в самой парадигме структурного программирования:

Синхронные запросы — RPC приостанавливает выполнение приложения до тех пор, пока сервер не вернет требуемые данные.

Статические отношения между компонентами — привязка клиентского процесса к серверным заглушкам происходит на этапе компиляции и не может быть изменена во время выполнения.

Для устранения этих недостатков были разработаны более совершенные механизмы реализации RPC:

асинхронные RPC, позволяющие избежать приостановки выполнения клиентского приложения посредством функций обратного вызова (call-back functions);

код заглушек вынесен в динамически подключаемые библиотеки.

Протокол взаимодействия RPC также может повлиять на работу системы. Рассмотрим гипотетический фрагмент кода:

for (i = 0, i < 1000, i++)

for (j = 0, j < 1000, j++)

RPC_call();^[8]

В этом случае вызов удаленной процедуры будет выполняться миллион раз. На каждой итерации будут выполняться действия не только по передаче данных и результатов, но и по управлению соединением. Это приведет не только к повышению нагрузки на сеть, но и снижению производительности системы в целом. В данном случае правильным решением является вынос функций установления и разрыва соединения за тело циклов, что противоречит самой идее RPC.^[9]

Привязка клиента и сервера

Привязка позволяет специфицировать отношения между удаленной процедурой и вызывающей ее программой. Привязка формируется после того, как два приложения установили логическое соединение и готовы обмениваться командами и данными.

Привязка может быть постоянной и непостоянной. При непостоянной привязке логическое соединение между двумя процессами устанавливается только на время удаленного вызова процедуры. Как только удаленная процедура возвращает значения, соединение разрывается. Активное соединение потребляет ресурсы, так как обе стороны должны хранить информацию о его состоянии. Использование временных соединений позволяет сберечь эти ресурсы. С другой стороны, на установку соединения требуется время и обмен служебными данными по сети, поэтому данный подход неприемлем для удаленных процедур, часто вызываемых одним и тем же процессом.

При постоянной привязке соединение, устанавливаемое для удаленного вызова процедуры, сохраняется и после того, как удаленная процедура возвращает управление. Это соединение может использоваться для последующих удаленных вызовов процедуры. Если в течение определенного интервала соединение не используется, оно разрывается. Такая схема удобна для приложений, делающих много удаленных вызовов процедур. В этом случае постоянная привязка позволяет делать вызовы и получать их результаты через одно и то же логическое соединение.

Заключение

Итак в данной работы были рассмотрены основные положения относящиеся к различным видам архитектуры клиент-сервер. Данная работа объясняет ключевые положения реализации данной технологии и описывает основные типы существующих реализаций клиент-серверного взаимодействия. Рассмотрены технологии от истоков в виде работы мэйнфреймами до новейших технологий реализации клиент – сервера с промежуточным сервером – так называемая трехзвенная архитектура.

И хотя в настоящее время технология клиент –серверного взаимодействия переживает период своего активнейшего развития на территории всей планеты, основы ей были положены еще 60 лет с появлением первых мейнфреймов. Еще тогда закладывались основные положения работы клиентов и серверов, виды их взаимодействия, ответственности.

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

При этом качество созданного сервиса будет завесить от понимания основ работы той или иной технологии, того или иного ПО и понимании правил взаимодействия между своим сервером и клиентами.

Список литературы

Книги

1. Олифер В.Г Олифер Н.А. «Компьютерные сети. Принципы, технологии, протоколы.» Изд-во Питер. 2006 – 958с
2. Таненбаум Э. «Компьютерные сети» «Классика Computer Science» 4 изд. «Питер» М.: 2003.
3. Таненбаум Э., Стеен М.«Распределенные системы. Принципы и парадигмы.» «Классика Computer Science» , изд. «Питер» М.: 2003.
4. Возняк С., Смит Дж. «Стив Джобс и я Подлинная история Apple», Издательство: Эксмот Год издания: 2012 Кол-во страниц: 288 ISBN: 9785699534524
5. Анатольев А.Г., 06.08.2013 Промежуточное ПО. Назначение, функции и виды middleware. Учебно-методические материалы для студентов кафедры АСОИУ

Журналы

1. Отказоустойчивость исследования сертификационный институт Uptime Institute https://uptimeinstitute.com/
2. Ю. Михайлов. История с яблоком. Наука и жизнь, № 12 (2001). Проверено 31 октября 2014.
3. Александр Авдуевский статья «Затерянный мир» в журнале «Журнал сетевых решений/LAN», № 03, 1997.
4. «The End of the Mainframe Era at NASA» NASA CIO Blog https://blogs.nasa.gov/NASA-CIO-Blog/2012/02/12/post_1329017818806/
5. Юрий Жуковский «Проектирование сервера под 1С» журнал «Компьютерное обозрение» http://ko.com.ua/proektirovanie_servera_pod_1s_66779

Документация

1. Remote Procedure Call Protocol Specification, Sun Microsystems, Inc. June 1988 http://www.ietf.org/rfc/rfc1057.txt
2. Oracle Fusion Middleware Documentation http://www.oracle.com/technetwork/ru/middleware/index.html

Интернет источники

1. Web Server Usage Statistics – портал интернет статистики, мониторинга и трендов. http://trends.builtwith.com/web-server
2. Knowledge Base of Relational and NoSQL Database Management Systems. http://db-engines.com/en/ranking
3. https://ru.wikipedia.org/wiki/API

1. «The End of the Mainframe Era at NASA» NASA CIO Blog https://blogs.nasa.gov/NASA-CIO-Blog/2012/02/12/post_1329017818806/ ↑

2. https://uptimeinstitute.com/ ↑

3. Web Server Usage Statistics – портал интернет статистики. ↑

4. Олифер В.Г Олифер Н.А. «Компьютерные сети. Принципы, технологии, протоколы.» с 600. ↑

5. Анатольев А.Г., 06.08.2013 Промежуточное ПО. Назначение, функции и виды middleware. Учебно-методические материалы для студентов кафедры АСОИУ ↑

6. Oracle Middleware http://www.oracle.com/technetwork/ru/middleware/index.html ↑

7. https://ru.wikipedia.org/wiki/API ↑

8. Анатольев А.Г., 06.08.2013 Промежуточное ПО. Назначение, функции и виды middleware. Учебно-методические материалы для студентов кафедры АСОИУ ↑

9. Remote Procedure Call Protocol Specification, Sun Microsystems, Inc. June 1988 http://www.ietf.org/rfc/rfc1057.txt ↑