Адресация в сети
Каждый клиент-сервер должен иметь свой собственный адрес для возможности его идентификации.
В более ранних версиях ПО и системах других производителей клиенты нумеровались последовательными натуральными числами начиная с нуля, такая нумерация вполне устраивала пока сеть не выходила за пределы одного участка и количество станций было порядка 30.
В настоящее время подобная адресация стала мала, а натуральное число не способно как-либо охарактеризовать Клиента, поэтому была создана новая территориальная адресация, подобная адресации принятой для международной сети Internet, с собственной сеткой адресов несколько отличной от Internet. Адресация также 32 битовая, причем старшие два байта такие же как в Internet.
Таблица 3 Структура адреса объекта
| Наименование поля | Длина, бит | Примечания |
| Номер сети | МПС – 0x0A - стандарт для Internet | |
| Номер дороги | Северная ж.д. – 0x1C - стандарт для Internet |
На младшие два байта наложена собственная структура.
Таблица 4
| Наименование поля | Длина, бит | Примечания |
| Номер отделения | до 8 Отделений на Дороге | |
| Номер узловой станции | до 16 узловых станций на Отделении | |
| Номер сети на данном узле | 16 сетей на одной узловой станции | |
| Локальный адрес в данной сети/подсети | до 32 клиентов в сети |
Таблица 5 Структура заголовка “Транспортного Протокола”
| Наименование поля | Длина, бит | Примечания |
| Байт синхронизации | Необходим для облегчения поиска начала сообщения, особенно при передаче по одной физической сети сообщений в разных протоколах. Значение 0xC1. | |
| Адрес источника | Используются только два младших байта адреса Клиента, т.к. старшие всегда одинаковы для системы в пределах Дороги. См. табл. 1.1. | |
| Адрес потребителя | См. табл. 1.1. | |
| Тип сообщения | Для возможности определения подсистемы реального времени и обеспечения маршрутизации, так как маршрутизация зависит от типа сообщения. | |
| Приоритет сообщения | Для возможности обгона сообщений которые особенно критичны ко времени передачи (синхронизация времени в сети ). | |
| Длина сообщения | Включая заголовок и тело сообщения. | |
| Номер сообщения (прикладной) | Номер сообщения конкретного Клиента. Поле используется для диагностики трафика сети и восстановления последовательности следования сообщений. | |
| Продолжение таблицы 2.3 | ||
| Резерв | Зарезервировано разработчиком для дальнейшего развития. | |
| Время создания сообщения | Стандартное время типа time_t – количество секунд, прошедших с 1 января 1970 г. Данное поле заимствовано от протоколов TCP-IP, FLEET. Поле используется для диагностики трафика сети и восстановления последовательности следования сообщений. Нарушение последовательности сообщений в системах реального времени недопустимо!!! | |
| Контрольная сумма заголовка | Поле используется ускорения выделения сообщения из общего потока и существенным образом влияет на дальнейшую обработку тела протокола, т.к. при неверном выделении заголовка получается неверная длина тела сообщения, что может вызвать самые печальные результаты “вплоть до вылета” программы. CRC заголовка считается по полиному восьмой степени P(x)=x8+x2+x+1, данный полином заимствован от системы ДЦМ - Дон, где использовался для подсчета CRC сообщения. Вероятность искажения при длине не более 16 байт составляет 10-15. | |
| Номер сообщения | Используется в протоколе нижнего уровня для нумерации сообщений, передаваемых между двумя соседними узлами. Поле не используется при подсчете CRC. | |
| Направление канала | 0 – прямой канал, 1 – обратный канал. Применялся в более ранних версиях. В настоящее время зарезервирован. | |
| Счетчик пройденных узлов | Поле используется при передаче управляющих сообщений, когда необходим автоматический поиск маршрута доставки, идея создания данного поля заимствована из протокола TCP-IP. Поле не используется при подсчете CRC. |
Тело сообщения, т.е. прикладной протокол для ТП не имеет никакого значения и никак не влияет на доставку сообщения.
Однако, надо заметить, что для систем реального времени сообщения с длиной более ~256 байт (максимальная длина тела сообщения рассчитывается на текущий момент передачи исходя из минимальной пропускной способности сети и текущего трафика в данном месте сети) снижают показатель качества доставки сообщения, исходя из этого при длине тела более ~256 (например: файловый обмен, обмен базами данных реального времени, передача видео и аудио информации) производится автоматическое разбиение на более мелкие части при передачи и восстановление при приеме.
Последние 4 байта сообщения - это CRC32 для тела сообщения. Для повышения производительности обработки сообщений CRC32 считаем только для тела, тем более что CRC заголовка уже подсчитано. CRC32 считается по стандартному полиному 32 степени CCITT-32 (MKKTT-32) P(x)=x32+x26+x23+x22+x16+x12+x11+x10+x8+x7+x5+x4+x2+x+1.
Транспортный протокол работает в двух моментах:
- при обмене между соседними клиентами, т.е. “Точка-Точка”;
- при выделении сообщения у Клиента.
При обмене “точка-точка” сообщения передаются непрерывно без ожидания ответа от соседа, при приёме формируется ответ точке источнику. После передачи сообщения включается таймер ожидания ответа, в случае отсутствия ответа более положенного времени таймаута (время таймаута рассчитывается автоматически Tтаймаут= F (физическая скорость обмена, трафик “точка-точка”)) посылается повторное сообщение.
Количество повторов определяется 0.5TМаксимальная задержка Клиента/Tтаймаута.
При обнаружении пропуска принятых сообщений передача сообщений для дальнейшей обработки приостанавливается и протокол переходит в режим ожидания приема повторного сообщения на время 0.5TМаксимальная задержка Клиента, при приеме повторного сообщения все остановленные сообщения передаются для дальнейшей обработки, если за это время сообщение не приходит, то всё ровно вся пачка накопленных сообщений передается дальше.
Таким образом, происходит восстановление последовательности следования сообщений при передаче “точка-точка”. Да, с определенной степенью вероятности может произойти потеря сообщения в пределах “точка-точка”, но лучше потерять одно сообщение, чем остановить трансляцию сообщений вообще, что можно наблюдать при передаче в протоколе TCP-IP.
Действующая сеть Реального Времени строится с учетом возможности потери сообщений в каком-то направлении, т.е. сообщения передаются одновременно по нескольким путям, что повышает вероятность надежной доставки сообщений Клиентам.
Работа Транспортного Протокола при приёме “Клиентом” сообщений производится в задаче “Диагностика”. Сообщения к “Клиенту” - приёмнику от одного “Клиента” - источника в системах Реального Времени приходят по нескольким путям (так должна быть организована топология сети), минимальное количество путей для кольцевых топологий - два, отсюда появляется задача выделения только первого сообщения и восстановления последовательности сообщений в случае пропадания сообщения по какому-либо направлению с учетом приходящих сообщений от других направлений.
Дата добавления: 2014-12-02; просмотров: 1228;