Remkomplekty.ru

IT Новости из мира ПК
2 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Субд на основе многоверсионной архитектуры

Многоверсионность данных и управление параллельными транзакциями

Первые работы по управлению параллельными транзакциями на основе многоверсионности появились еще 20-30 лет назад, однако интерес к версионным техникам не ослаб и сегодня — многоверсионные алгоритмы разрабатываются сейчас для систем совместной работы над мультимедиа-проектами, распределенных мобильных баз данных и адаптируются для использования в XML СУБД.

Рассмотрим основные алгоритмы управления параллельными транзакциями, основанные на концепции версионности.

Первые работы, посвященные управлению параллельными транзакциями на основе многоверсионности (multiversion concurrency control, MVCC), появились еще в конце 70-х — начале 80-х годов. Исходные статьи были написаны Ридом и коллективом авторов во главе с Байером [1-3], идеи которых были развиты в работах Стернса и Розенкранца [10], а также Бернштейна и Гудмена [6]. Основная идея MVCC заключается в том, что в базе данных допускается существование нескольких «версий» одного и того же элемента данных, что позволяет улучшить ряд характеристик СУБД, наиболее важных для следующих категорий приложений.

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

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

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

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

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

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

Приведем далее обзор основных многоверсионных алгоритмов управления параллельными транзакциями, различные варианты и комбинации которых были реализованы в Oracle, Postgres и MySQL. В завершение обзора сравним алгоритмы и обсудим трудности, с которыми приходится сталкиваться при их применении. Будем говорить об алгоритмах работы многоверсионного планировщика, поскольку именно этот компонент СУБД отвечает за сопоставление конкретных данных логическим операциям над ними. Будем также рассматривать только такие планировщики, которые имитируют поведение обособленных транзакций.

Временные метки

В [6] Бернштейн и Гудмен пишут, что наиболее ранний известный им алгоритм работы планировщика для версионной СУБД основан на временных метках (multiversion timestamp ordering, MVTO). Этот планировщик обрабатывает операции таким образом, чтобы суммарный результат выполнения операций был эквивалентен последовательному выполнению транзакций. Порядок сериализации задается порядком временных меток, которые получают транзакции во время старта. Временные метки также используются для идентификации версий данных при чтении и модификации — каждая версия получает временную метку той транзакции, которая ее записала. Планировщик не только следит за порядком выполнения действий транзакций, но также отвечает за трансформацию операций над данными в операции над версиями — каждая операция вида «прочитать элемент данных x», должна быть преобразована планировщиком в операцию: «прочитать версию y элемента данных x».

Временную метку, полученную транзакцией ti в начале ее работы, будем обозначать как ts(ti), операцию чтения транзакцией ti элемента данных x как ri(x). Для обозначения того, что транзакция ti читает версию элемента данных x, созданную транзакцией tk, будем писать ri(xk), для обозначения того, что транзакция ti записывает версию элемента данных x, будем использовать запись wi(x). Опишем алгоритм работы планировщика MVTO.

Планировщик преобразует операцию ri(x) в операцию ri(xk), где xk — это версия элемента x, помеченная наибольшей временной меткой ts(tk), такой что ts(tk)

Различные архитектурные решения, используемые при реализации многопользовательских СУБД. Краткий обзор СУБД

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

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

3.1. Централизованная архитектура

При использовании этой технологии база данных , СУБД и прикладная программа ( приложение ) располагаются на одном компьютере (мэйнфрейме или персональном компьютере) (рис.3.1.). Для такого способа организации не требуется поддержки сети и все сводится к автономной работе. Работа построена следующим образом:

  • База данных в виде набора файлов находится на жестком диске компьютера.
  • На том же компьютере установлены СУБД и приложение для работы с БД .
  • Пользователь запускает приложение. Используя предоставляемый приложением пользовательский интерфейс, он инициирует обращение к БД на выборку/обновление информации.
  • Все обращения к БД идут через СУБД, которая инкапсулирует внутри себя все сведения о физической структуре БД.
  • СУБД инициирует обращения к данным, обеспечивая выполнение запросов пользователя (осуществляя необходимые операции над данными).
  • Результат СУБД возвращает в приложение.
  • Приложение, используя пользовательский интерфейс, отображает результат выполнения запросов.
Читать еще:  Минусы архитектуры фон неймана

Подобная архитектура использовалась в первых версиях СУБД DB2 , Oracle , Ingres [ [ 3.1 ] ].

Многопользовательская технология работы обеспечивалась либо режимом мультипрограммирования (одновременно могли работать процессор и внешние устройства – например, пока в прикладной программе одного пользователя шло считывание данных из внешней памяти, программа другого пользователя обрабатывалась процессором), либо режимом разделения времени (пользователям по очереди выделялись кванты времени на выполнение их программ). Такая технология была распространена в период «господства» больших ЭВМ (IBM-370, ЕС-1045, ЕС-1060). Основным недостатком этой модели является резкое снижение производительности при увеличении числа пользователей.

3.2. Технология с сетью и файловым сервером (архитектура «файл-сервер»)

Увеличение сложности задач, появление персональных компьютеров и локальных вычислительных сетей явились предпосылками появления новой архитектуры файл-сервер . Эта архитектура баз данных с сетевым доступом предполагает назначение одного из компьютеров сети в качестве выделенного сервера, на котором будут храниться файлы базы данных [ [ 3.2 ] ]. В соответствии с запросами пользователей файлы с файл-сервера передаются на рабочие станции пользователей, где и осуществляется основная часть обработки данных. Центральный сервер выполняет в основном только роль хранилища файлов, не участвуя в обработке самих данных ( рис. 3.2.).

Работа построена следующим образом:

  • База данных в виде набора файлов находится на жестком диске специально выделенного компьютера (файлового сервера).
  • Существует локальная сеть, состоящая из клиентских компьютеров, на каждом из которых установлены СУБД и приложение для работы с БД.
  • На каждом из клиентских компьютеров пользователи имеют возможность запустить приложение. Используя предоставляемый приложением пользовательский интерфейс, он инициирует обращение к БД на выборку/обновление информации.
  • Все обращения к БД идут через СУБД, которая инкапсулирует внутри себя все сведения о физической структуре БД, расположенной на файловом сервере.
  • СУБД инициирует обращения к данным, находящимся на файловом сервере, в результате которых часть файлов БД копируется на клиентский компьютер и обрабатывается, что обеспечивает выполнение запросов пользователя (осуществляются необходимые операции над данными).
  • При необходимости (в случае изменения данных) данные отправляются назад на файловый сервер с целью обновления БД.
  • Результат СУБД возвращает в приложение.
  • Приложение, используя пользовательский интерфейс, отображает результат выполнения запросов.

В рамках архитектуры » файл-сервер » были выполнены первые версии популярных так называемых настольных СУБД , таких, как dBase и Microsoft Access.

В литературе [ [ 3.2 ] ] указываются следующие основные недостатки данной архитектуры:

Трехуровневая архитектура СУБД;

Концептуальная, логическая и физическая модели предметной области

Трехуровневая архитектура СУБД

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

Концептуальный уровень отражает предметную область в самом общем виде. Он определяет содер­жание и структуру предметной области безотносительно к моделям данных (см. раздел 2) и типу используемой СУБД. Этот уровень должен быть понятен пользователю и полностью независим от того, как данные будут храниться в действительности. Изменения в этой модели должны производиться только при изменениях в реальном мире, чтобы эта модель продолжала быть отражением предметной области.

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

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

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

В 1978 году комитетом ANSI/SPARC (ANSI, American National Standard Institute – Национальный институт стандартизации США; SPARC, Standard Planning and Requirements Committee – Комитет планирования стандартов и норм) официально зафиксировано различие между логическим и физическим представлением данных. В частности, была предложена обобщенная структура систем с базой данных.

Эта структура получила название трехуровневой архитектуры, включающей внутренний, концептуальный и внешний уровни (рис. 2.1).

Введение трехуровневой архитектуры БД позволило отделить пользовательское представление БД от ее физического представления.

Необходимость такого отделения обусловлена, прежде всего, следующими причинами:

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

· обращение пользователя к БД на должно зависеть от особенностей хранения в ней данных;

· администратор БД может при необходимости изменять структуру хранения данных в базе, включая концептуальную структуру БД, причем данные действия не должны влиять на пользовательские представления данных;

· внутренняя структура хранения данных не должна зависеть от изменения физических устройств хранения информации.

Рис. 3.2. Трехуровневая архитектура СУБД

Таким образом, в трехуровневой модели СУБД:

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

Читать еще:  Архитектура приложения при разработке

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

Внешний уровень – структурный уровень БД, определяющий пользовательские представления данных. Каждый пользователь или группа пользователей получают свое собственное представление данных в БД. Такое пользовательское описание элементов данных и отношений между ними можно напрямую вывести из концептуальной схемы. Совокупность различных пользовательских представлений данных и образует внешний уровень [20, С.9-13].

В разделе 2.1 был показан пример схемы данных (рис. 2.1). Под схемой данных (схемой базы данных) понимается общее описание базы данных. В соответствии с трехуровневой архитектурой различают и три типа схем базы данных.

Внешнему уровню представления БД соответствуют, как правило, несколько внешних схем (подсхем) БД. Каждая из таких схем соответствует представлению данных определенной группы пользователей СУБД.

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

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

Исходя из различных схем БД в трехуровневой модели, следует, что СУБД должна устанавливать соответствие и следить за непротиворечивостью схем: внешними, концептуальной и внутренней.

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

В теории и практике баз данных принято различать понятия «описание базы данных» и «база данных» [20, С.12-13].

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

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

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

Независимость бывает двух типов:

· логическая – полная защищенность внешних схем от изменений, которые вносятся в концептуальную схему;

· физическая – защищенность концептуальной схемы от изменений, которые вносятся во внутреннюю схему.

Понятие СУБД. Архитектура СУБД. Классификация СУБД

Понятие. Система управления базами данных (СУБД) – это сов-сть языковых и програмн средств, предназначенных для создания, ведения и совместного использования БД многими пользователями.

Современная СУБД содержит в своем составе программные средства создания баз данных (язык описания и манипулирования данными, визуальные средства, отладчики), средства работы с данными и сервисные средства. Функции элементов СУБД: — язык описания служит для преобразования логической модели в физическую; — язык манипулирования реализует операции над данными; — визуальные средства привлекаются в процессе проектирования графических объектов; — программы отладки соединяют и тестируют блоки программы управления, созданной БД; — средства работы с БД обеспечивают удобный интерфейс с пользователем; сервисные средства привлекают к работе с БД другие программы (эксель).

Архитектура. В среде СУБД можно выделить след. пять основных компонентов.

Аппаратное обеспечение. Одни СУБД предназначены для работы только с конкр типами ОС или оборудования, другие могут работать с широким кругом аппаратного обеспечения и различными ОС. Для работы СУБД обычно требуется некоторый минимум оперативной и дисковой памяти, но ее может быть недостаточно для достижения приемлемой производительности системы.

Программное обеспечение. Этот компонент включает операционную систему, программное обеспечение самой СУБД, прикладные программы, включая и сетевое программное обеспечение, если СУБД используется в сети. Обычно приложения создаются на языках третьего поколения, таких как С, COBOL, Fortran, Ada или Pascal, или на языках четвертого поколения, таких как SQL, операторы которых внедряются в программы на языках третьего поколения.

Данные – наиболее важный компонент с точки зрения конечных пользователей. База данных содержит как рабочие данные, так и метаданные, т.е. «данные о данных».

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

Пользователи: клиенты БД, администратор БД, прикладн. программисты.

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

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

Третий компонент СУБД – ее ядро (DBMS Engine) выполняет функцию посредника между подсистемой средств проектирования и обработки и данными. Ядро СУБД получает запросы от двух других компонентов, выраженные в терминах таблиц, строк и столбцов, и преобразует эти запросы в команды операционной системы, выполняющие запись и чтение данных с физического устройства.

Microsoft представляет два различных ядра для Access 2003: Jet Engine и SQL Server. Ядро Jet Engine используется для персональных и коллективных баз данных небольшого объема. Ядро SQL Server предназначено для крупных баз данных.

Читать еще:  Архитектура с общей шиной

По степени универсальности:

СУБД общего назначения не ориентированы на какую-либо конкретную предметную область или на информационные потребности конкретной группы пользователей. Они не всегда позволяют добиться требуемой производительности и/или удовлетворить заданные ограничения по объёму памяти, предоставляемой для хранения БД.

Тогда — специализированную СУБД для данного конкретного применения. Примером специализированной СУБД может быть система IMBASE, используемая для автоматизации проектных и конструкторских разработок.

По типу модели данных:

— иерархические. Первой такая СУБД — система IMS (Information Management System) компании IBM;

— сетевые. Первой сетевой СУБД считается система IDS (Integrated Data Store), разработанная компанией General Electric немного позже системы IMS;

— реляционные. Первые коммерческие реляционные СУБД от компаний IBM, Oracle Corporation, Relation Technology Inc. и других поставщиков появились в начале 80-х годов. Реляционные СУБД просты в использовании, повышают производительность программистов при разработке прикладных программ, хорошо приспособлены для работы в архитектуре клиент/сервер, позволяют параллельную обработку БД, хорошо приспособлены к графическим пользовательским интерфейсам.

— объектно-реляционные (постреляционные). Объектно-реляционные СУБД продолжают использовать стандартный язык запросов для реляционных БД – SQL, но с объектными расширениями;

— объектно-ориентированные. В основе объектно-ориентированных СУБД лежит объектно-ориентированная модель обработки данных.

— многомерные, в основе которых лежит многомерная модель данных.

На самом общем уровне все СУБД можно разделить на:

— профессиональные (промышленные), которые представляют собой программную основу для разработки автоматизированных систем управления крупными экономическими объектами. (Oracle, DB2, Sybase, Informix, Inqres, Progress).

— персональные (настольные). (DBASE,FoxBase, FoxPro, Clipper, Paradox, Access.)

Многоверсионная архитектура

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

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

По причине использования многоверсионной архитектуры (называемой также MGA — Multi-generational architecture) для Firebird нет необходимости в двухфазной блокировке, используемой другими СУБД для управления многопользовательской работой.

Похожие главы из других книг:

Архитектура

Архитектура Если вы соблюдаете три закона и пишете тесты раньше рабочего кода, вы сталкиваетесь с дилеммой. Часто вы точно знаете, какой код нужно написать, но три закона приказывают сначала написать модульный тест, который не пройдет, потому что код еще не существует!

Архитектура PowerPC

Архитектура PowerPC Архитектура PowerPC обладает всеми обычными характеристиками архитектуры RISC: команды фиксированной длины, операции регистр-регистр, простые режимы адресации и большой набор регистров. Но есть и характеристики, отличающие ее отдругих.Как уже упоминалось,

Архитектура STREAMS

Архитектура STREAMS Подсистема STREAMS обеспечивает создание потоков — полнодуплексных каналов между прикладным процессом и драйвером устройства[57]. С другой стороны, архитектура STREAMS определяет интерфейсы и набор правил, необходимых для взаимодействия различных частей этой

Архитектура TCP/IP

Архитектура TCP/IP Архитектура семейства протоколов TCP/IP основана на представлении, что коммуникационная инфраструктура включает три объекта: процессы, хосты, и сети. Процессы являются основными коммуникационными объектами, поскольку между процессами, в конечном итоге,

Внутренняя архитектура

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

3.6 Архитектура TCP

3.6 Архитектура TCP TCP реализуется на хостах. Наличие TCP на каждом конце соединения обеспечивает для доставки данных локального приложения следующие возможности:? Точность? Сохранение последовательности? Полноту? Исключение дублированияБазовый механизм для реализации

3.7 Архитектура UDP

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

19.7 Архитектура HTTP

19.7 Архитектура HTTP Как и в gopher, извлечение гипертекстового документа достаточно просто. Как показано на рис. 19.3, клиент соединяется с сервером WWW, извлекает часть документа (обычно ее называют страницей. — Прим. пер.) и закрывает соединение. Браузер выводит извлеченную

Многоверсионная архитектура InterBase

Многоверсионная архитектура InterBase InterBase — это первая в мире СУБД, в которой реализована многоверсионная архитектура. Именно многоверсионная архитектура позволяет организовать взаимодействие пользователей таким образом, что читающие пользователи не блокируют пишущих,

13 Открытая архитектура

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

32 Re: Архитектура

32 Re: Архитектура Что произошло с архитектурой программного обеспечения? В типичном приложении для малого бизнеса или в стандартном коммерческом пакете зачастую бывает трудно обнаружить присутствие хоть какой-то структуры. Архитектура — будь то внутренняя

Архитектура корпоративной PKI

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

Архитектура мостового УЦ

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

Архитектура приватности

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

Архитектура безопасности

Архитектура безопасности Этот раздел запроса на предложения содержит описание требований безопасности для разных компонентов архитектуры PKI, включая требования отраслевых или государственных стандартов сертификации. К ним относятся:* способы контроля хранения

Ссылка на основную публикацию
Adblock
detector