Вопрос 24.

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

Стандартизированный протокол передачи данных также позволяет разрабатывать интерфейсы (уже на физическом уровне), не привязанные к конкретной аппаратной платформе и производителю (например, USB, Bluetooth).

Сетево́й протоко́л — набор правил и действий (очерёдности действий), позволяющий осуществлять соединение и обмен данными между двумя и более включёнными в сеть устройствами.

Разные протоколы, зачастую, описывают лишь разные стороны одного типа связи; взятые вместе, они образуют стек протоколов. Названия «протокол» и «стек протоколов» также указывают на программное обеспечение, которым реализуется протокол.

Новые протоколы для Интернета определяются IETF, а прочие протоколы — IEEE или ISO. ITU-T занимается телекоммуникационными протоколами и форматами.

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

Вопрос 25.Уровневая сетевая архитектура.

В этой схеме собраны почти все варианты названий трех уровней распределенного приложения. Чтобы избежать путаницы, будем именовать уровни так: 1st tier, 2nd tier и 3rd tier, по причине краткости написания. Выбирать названия по другим критериям слишком сложно. Называть 3-х уровневую архитектуру N-уровневой вероятно не стоит, т.к. эти N уровней, обычно, появляются как более детальное изображение той же 3-х уровневой схемы, не внося принципиально новых идей. N-уровневые схемы удобны чтобы показать систему с точки зрения развертывания и администрирования. Но с точки зренияразвертывания и администрирования. Но с точки зрения разработки эти дополнительные уровни малоинтересны.

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

2-x уровневая архитектура (Клиент-Сервер)В классической архитектуре клиент-сервер, бизнес-логика может располагаться как у клиента, так и на сервере. В результате существует тенденция смешивания бизнес-логики с интерфейсом пользователя и/или со структурой БД.

3-x уровневая архитектура (идеальный вариант)

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

Интересно отметить, что сервисы для вызова бизнес-логики (2nd tier), относятся к 1st tier. А вот интерфейс с базой данных (или любым источником данных) - сразу к 3rd tier. Такой подход позволяет четко очертить границы уровня бизнес-логики и отличие 3-х уровневого подхода от 2-х уровневого (клиент-сервер).

3-x уровневая архитектура (фактический вариант)

На практике, мы имеем нечто подобное. По различным причинам бизнес-логика остается на 1st и 3rd tier. Это может быть оправдано, если не приведет к перегрузке уровня, на котором находится ненормированный код. И если этот код легко можно перенести в 2nd tier объекты. Например, поместив бизнес-логику в хранимые процедуры в 3rd tier, мы можем получить большой выигрыш в производительности. Если же эти хранимые процедуры написаны на Java, то перенести их в 2nd tier будет несложно. А вот бизнес-логика на 1st tier распространена повсеместно(как уже упоминалось), и, обычно, связана с неудачной архитектурой.

Вопрос 26.Топология сетей передачи данных. Все компьютеры в локальной сети соединены линиями связи. Геометрическое расположение линий связи относительно узлов сети и физическое подключение узлов к сети называется физической топологией. В зависимости от топологии различают сети: шинной, кольцевой, звездной, иерархической и произвольной структуры.Различают физическую и логическую топологию. Логическая и физическая топологии сети независимы друг от друга. Физическая топология - это геометрия построения сети, а логическая топология определяет направления потоков данных между узлами сети и способы передачи данных.

В настоящее время в локальных сетях используются следующие физические топологии:

физическая "шина" (bus);

физическая “звезда” (star);

физическое “кольцо” (ring);

Если компьютеры подключены вдоль одного кабеля [сегмента (segment)], топология называется шиной. В том случае, когда компьютеры подключены к сегментам кабеля, исходящим из одной точки, или концентратора, топология называется звездой. Если кабель, к которому подключены компьютеры, замкнут в кольцо, такая топология носит название кольца.

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