Локальная сеть корвет

[forth32]

Сеансовый уровень. Протокол обмена пакетами.

Как я уже говорил выше, обмен всегда начинает сервер. Широковещательный режим пока не рассматриваем, только адресный.

1. Фаза адреса. Сервером отсылается адресный пакет, выбирающий то РМУ, с которым сервер желает взаимодействовать. РМУ, адрес которого указан в пакете, отвечает серверу пакетом Y. Остальные РМУ переходят в пассивное состояние и ждут нового адресного пакета.

Следующие фазы зависят от того, в какую сторону планируется передача данных. Для отправки данных от сервера к клиенту протокол выглядит так:

2. Фаза типа данных. Сервером отсылается пакет R, содержащий тип данных и, если надо, адрес загрузки. Клиент отвечает пакетом Y.

3. Фаза передачи данных. Сервер начинает отсылать пакеты типа D с данными, клиент их принимает, распаковывает и размещает в своей памяти. После каждого принятого пакета D клиент отвечает пакетом Y, если пакет D принят успешно. В случае ошибок - неправильной КС, сбоя последовательности нумерации пакетов итд, клиент отвечает пакетом N. Тогда сервер перепосылает тот же самый пакет D с тем же номером.

4. Фаза конца данных. После передачи последнего пакета D сервер отправляет пакет Z. Клиент отвечает пакетом Y и приступает к обработке полученных данных (об этом далее).

При запросе сервером данных от клиента протокол будет немного другим:

2. Фаза типа данных. Сервером отсылается пакет S, содержащий тип данных и, если надо, адреса начала и конца области памяти. Клиент отвечает пакетом Y, затем, срзу же, пакетом R, содержащим в себе копию параметров (тип данных и адреса) из полученного пакета S. Сервер подтверждает прием пакетом Y.

3. Фаза передачи данных. Клиент начинает отсылать пакеты типа D с данными, сервер их принимает, распаковывает и делает с ними что ему нужно. После каждого принятого пакета D сервер отвечает пакетом Y, если пакет D принят успешно. При ошибке сервер отвечает пакетом N и клиент перепосылает тот же пакет D.

4. Фаза конца данных. После передачи последнего пакета D клиент отправляет пакет Z. Сервер отвечает пакетом Y, а клиент переходит в пассивное состояние с снова ждет адресного пакета.

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

На всякий случай привожу диаграмы взаимодействия сервера и клиента

Загрузка данных в клиента от сервера:

Сервер   Клиент (РМУ1)
  A (1)
                   Y
   R
                   Y
   D 
                   Y  (N при ошибке)
   D 
                   Y
  ........................
   Z
                   Y

Выгрузка данных на сервер из клиента:

Сервер   Клиент (РМУ1)
  A (1)
                   Y
   S
                   Y
                   R
   Y 
                   D 
   Y  (N при ошибке)
                   D
   Y
  ........................
                   Z
    Y

Теперь относительно обработки клиентом принятых данных. Для типов 0 и 9 принимается текстовая строка, которая тут же выводится на экран РМУ. Для типа 0 экран предварительно очищается. Для типа 2 принимается массив данных, содержащий упакованную в токены бейсик-программу. Массив размещается в памяти, начиная с адреса 91D1h, и может заполнять память вплоть до BF00h. Массив имеет такую структуру.

+00   1       FFh
 ------- программная строка -------
+01   2       адрес следующей программной строки
+03   2       номер данной строки
+05   nnn    тело данной строки, заканчиватеся нулем.
Далее идет следующая программная строка, и так до конца всей программы.

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

Для типа данных 3 и 7 происходит прием последовательности байтов и размещение их, начиная с указанного в пакете R адреса. При этом не прверяется, имеется ли в этом месте именно память. Так что можно писать по любому адресу - и в АЦЗУ, и в регистры периферии, и в область ROM (что приведет к записи в теневую память по тем же адресам). Для типа данных 3 после приема всех байтов управление возвращается в командную строку бейсика. Для типа данных 7 происходит передача управления по начальному адресу загрузки данных. Так можно передать в РМУ самозапускаемую программу в машинных кодах. Я пробовал TETRIS и GONKI - запускаются и работают. Кстати, если передать в РМУ данные типа 7 нулевой длины (то есть за пакетом R сразу передать пакет Z, не передавая данные), то можно просто передать управление по указанному в пакете R адресу. Так можно запустить предварительно загруженный в память код, ну или, например, перезагрузить корвет, передав управление по адресу 0.

Ну и, наконец, COM-сообщение - это сообщение, формируемое оператором бейсика COM. Его можно вызвать и из программы, и непосредственно из командного режима. После ввода сообщения формируется флаг наличия сообщения (становится равным 1), и его можно проверить, запросив данные типа 6. Текст сообщения можно получить, запросив данные типа 5, при этом флаг наличия сообщения автоматически сбрасывается в 0.
В коде ОПТС2 имеется одна особенность. После старта бейсика тело сообщения оказывается целиком заполнено кодом FF, и флаг наличия сообщения также устанавливается равным FF. Проще говоря, бейсик не подчищает эту область памяти, заполненную FF в процессе теста RAM при старте ОПТС. Это явный баг в коде, но его можно использовать для отлова по сети момента перезагрузки РМУ. После первого чтения строки байтов FF флаг наличия сообщения автоматически сбросится и дальше все будет работать как обычно.

COM-сообщения - очень полезный инструмент для взаимодействия с сервером. В своей серверной программе на PC я сделал режим, при котором прямо с РМУ можно запросить загрузку данных из файла на сервере, например COM "@L PROG.BAS" пересылает программу PROG.BAS с PC на РМУ. Так можно эмулировать возможности дискового бейсика на ПК8010, не имеющем дисковода.

Вот вроде пока и все, что я хотел рассказать по сети корвет.

[Advertiser]