255 Протокольный стек TCP/IP
Комплект протоколов TCP/IP (Transmission Control Protocol/Internet Protocol) разрабатывался для сети Интернет (Internet Protocol Suite), в наст. время он широко распространен как в локальных, так и в глобальных сетях. Комплект протоколов Интернета состоит из набора общедоступных (по сети) документов RFC (Request For Comments—предложения к обсуждению), созданных коллективными усилиями мирового сетевого сообщ-ва. Передача данных в Интернете основана на принципе коммутации пакетов, в соответствии с которым поток данных, передаваемых от одного узла к др., разбивается на пакеты, передающиеся в общем случае через сист. коммуникаций и маршрутизаторов независимо др. от др. и вновь собирающиеся на приемной стороне. Весь комплект базируется на IP - протоколе негарантированной доставки пакетов (дейтаграмм) без установления соединения (unreliable connectionless packet delivery). Инф. в TCP/IP передается пакетами со стандартизованной структурой, называемыми IP-дейтаграммами (IP Datagram), имеющими поле заголовка (IP Datagram Header) и поле данных (IP Datagram Data). Формат заголовка приведен на рис, где он показан в виде 32-битных слов. Конечные узлы — отправители и получатели инф., называются хостами (host), промежуточные устр-ва, оперирующие IP-пакетами (анализирующие и модифицирующие инф. IP-заголовков), называют шлюзами (gateway).
Слово\Бит 0 3 4 7 8 1516 19 31
1
|
Версия IP
|
Длина заголовка
|
Тип обслуживания
|
Общая длина дейтограммы
|
2
|
Идентификатор
|
Флаги
|
Местополож. фрагмента в дейтаграмме
|
3
|
Время жизни TTL
|
Протокол
|
Контрольная сумма заголовка
|
4
|
IP адрес отправителя
|
5
|
IP адрес получателя
|
6
|
опции
|
В дейтаграмму длиной 576 байт умещается 512-байтный блок данных и 64-байтный заголовок (размер заголовка может составлять 20-60 байт). Длина дейтаграммы определяется сетевым ПО так, чтобы она умещалась в поле данных сетевого кадра, осущ-го ее транспортировку. Поскольку по пути следования к адресату могут встречаться сети с меньшим размером поля данных кадра, IP специфицирует единый для всех маршрутизаторов метод сегментации — разбивки дейтаграммы на фрагменты (тоже IP-дейтаграммы) и реассемблирования — обратной ее сборки приемником. Фрагментированная дейтаграмма собирается только ее окончательным приемником, поскольку отдельные фрагменты могут добираться до него различными путями. Порядок сборки опред-ся смещением фрагмента, перекрытие фрагментов и даже выход фрагмента за заявленный размер собир-го пакета, как правило, не контролируются. На основе этих свойств алгоритма сборки «умельцы» осуществляют взлом сетевых ОС. Возможна конкатенация — соединение нескольких дейтаграмм в одну и сепарация — обратное действие.
В наст. время готовится переход на протокол IP v.6, который имеет следующие основные отличия: Расширение поля адреса с 32 до 128 бит.Обеспечение возможности автоконфигурирования узлов. Выравнивание полей заголовка с целью ускорения обработки пакетов. Обеспечение возможностей для большей расширяемости протокола. Дальнейшее изложение относится к существующей 32-битной адресации IP v.4
Прототипное проектирование экономической информационной системы (ЭИС) (RAD-технологии). Основные возможности и преимущества быстрой разработки прототипа ЭИС при использовании RAD-технологии.
Один из подходов к разработке прикладного ПО в рамках спиральной модели ЖЦ - быстраяй разработка приложений, или RAD. Подход RAD предусматривает наличие 3х составляющих:
- группа разработчиков (3-7чел), кот. вып-ет работы по проектир-ю отдельных подсистем ПО;
- пр-венный график (до 3 мес);
- повторяющийся цикл, при кот. разработчики реализуют в продукте треб, полученные в рез-те вз-действия с заказчиком.
ЖЦ ПО в подходе RAD вкл-ет 4стадии:
1) анализ и планирование треб; 2) проектир-е; 3) реализация; 4) внедрение.
1. Анализ и планирование треб. На этом этапе пользователи:
- опред-ют ф-ции, кот. должна вып-ть сист;
- выделяют ф-ции, требующие проработки в первую очередь;
- опис-ют инфо-ные потребности.
На данной стадии реш-ся след. задачи: огранич-ся масштаб проекта; устанав-ся временные рамки для кажд. стадии; опред-ся возможность реализации проекта в заданных размерах фин-рования, на имеющихся аппаратных средствах и т.п.
Рез-т вып-ния: а) список ф-ций будущего ПО ЭИС; б) предварительные модели ПО.
2. Проектир-е. На данной стадии вып-ся след. действия:
- более детально рассм-ся процессы системы;
- при необходимости для кажд. эл-тарного процесса создается частичный прототип: экранная форма, диалог, отчет;
- устанавливаются требэ разграничения доступа к данным;
- опред-ся состав док-тации.
После опред-я состава процессов оценивается кол-во ф-циональных точкек (входной эл-т – входной док-т или экранная форма; выходной эл-т – отчет, док-т, экранная форма; запрос; интерфейс приложения) и принимается реш-е о разделении ЭИС на подсист.
Рез-т данной стадии: а) общая инфо-ная модель сист; б) ф-циональные модели сист; в) разработанные интерфейсы подсистем; г) построенные прототипы экранных форм, отчетов, диалогов.
3. Реализация. На этой стадии вып-ся разработка приложения:
- построение реальной системы на основе полученных моделей;
- пользователи оценивают получаемые рез-ты и вносят коррективы.
Тестирование сист. осущ-ся в процессе разработки.
Реализация сист. завершается:
- осущ-ем анализа использования данных и опред-я необходимости их распределения;
- физическим проектир-ем БД;
- формулировкой треб. к аппаратным ресурсам;
- завершением разработки док-тации проекта.
Рез-том стадии явл-ся готовая сист, удовлет-щая всем треб.
4. Внедрение. Здесь производится обучение пользователей.
Подход RAD хорош для относит-но небольших проектов, разрабатываемых для конкретного заказчика. Подход RAD не применим для построения сложных расчетных прогр, операцэ систем или прогр, содержащих большой объем уникального кода.
Do'stlaringiz bilan baham: |