Свойства канала передачи данных word
Использование каналов
В Nucleus SE каналы определяются на этапе сборки. В каждом приложении может быть до 16 каналов. Если в приложении не сконфигурирован ни один канал, ни структуры данных, ни код служебных вызовов, относящиеся к каналам, не будут включены в приложение.
Канал передачи данных – набор хранилищ, размер каждого из которых позволяет размещать один элемент данных заданной пользователем длины в байтах. Доступ к данным контролируется таким образом, чтобы ими могли безопасно пользоваться несколько задач. Задачи могут записывать данные в канал, пока не заполнятся все области. Задачи могут читать данные из канала, причем данные поступают по принципу FIFO. Попытка записи в переполненный канал или чтения из пустого канала может привести к ошибке или приостановке задачи, в зависимости от выбранных настроек вызовов API и конфигурации Nucleus SE.
Каналы и очереди
Настройка каналов
Количество каналов
Выбор ненулевого значения служит главным активатором каналов. Этот параметр используется при определении структур данных и от его значения зависит их размер (об этом подробнее в следующей статье). Кроме того, ненулевое значение активирует настройки API.
Активация вызовов API
NUSE_PIPE_SEND
NUSE_PIPE_RECEIVE
NUSE_PIPE_JAM
NUSE_PIPE_RESET
NUSE_PIPE_INFORMATION
NUSE_PIPE_COUNT
По умолчанию им присваивается значения FALSE, таким образом все служебные вызовы отключены, блокируя включение реализующего их кода. Для настройки каналов в приложении нужно выбрать необходимые служебные вызовы API и присвоить им значение TRUE.
Ниже приведен фрагмент кода из файла nuse_config.h по умолчанию.
Если функции API активированы, но в приложении нет каналов (кроме NUSE_Pipe_Count(), который разрешен всегда), произойдет ошибка компиляции. Если ваш код использует вызов API, который не был активирован, произойдет ошибка компоновки, так как код реализации не был включен в приложение.
Служебные вызовы каналов
Nucleus RTOS поддерживает десять служебных вызовов, связанных с каналами, которые предоставляют следующий функционал:
Служебные вызовы записи и чтения из каналов
Запись в канал
Служебный вызов Nucleus RTOS API для записи в канал очень гибкий, что позволяет приостанавливать задачи неявным образом либо с таймаутом, если операцию нельзя завершить немедленно (например, при попытке записи в переполненный канал). Nucleus SE имеет аналогичный вызов, но приостановка задач опциональна, а таймаут не реализован.
Nucleus RTOS также предоставляет службу для трансляции (broadcast) на канал, но в Nucleus SE она не поддерживается. Она будет описана в разделе «Нереализованные вызовы API» в следующей статье.
Прототип служебного вызова:
STATUS NU_Send_To_Pipe(NU_PIPE *pipe, VOID *message, UNSIGNED size, UNSIGNED suspend);
Этот служебный вызов API поддерживает основной функционал Nucleus RTOS API.
Прототип служебного вызова:
STATUS NUSE_Pipe_Send(NUSE_PIPE pipe, U8 *message, U8 suspend);
Вариант кода функции API NUSE_Pipe_Send() (после проверки параметров) выбирается при помощи условной компиляции в зависимости от того, активирована ли поддержка вызовов API для блокировки (приостановки) задач или нет. Ниже мы рассмотрим оба варианта.
Если блокировка отключена, код этого вызова API довольно прост:
Если блокировка задач активирована, код становится более сложным:
Некоторые пояснения могут быть полезными.
Код заключен в цикл do…while, который выполняется, пока параметр приостановки задач имеет значение NUSE_SUSPEND.
Чтение из канала
Служебный вызов Nucleus RTOS API для чтения из канала очень гибкий, что позволяет приостанавливать задачи неявным образом или с таймаутом, если операцию нельзя завершить немедленно (например, при попытке чтения пустого канала). Nucleus SE имеет аналогичный служебный вызов, но приостановка задач опциональна, а таймаут не реализован.
Вызов для чтения из канала в Nucleus RTOS
Прототип служебного вызова:
STATUS NU_Receive_From_Pipe(NU_PIPE *pipe, VOID *message, UNSIGNED size, UNSIGNED *actual_size, UNSIGNED suspend);
Вызов для чтения из канала в Nucleus SE
Этот служебный вызов API поддерживает основной функционал Nucleus RTOS API.
Прототип служебного вызова:
STATUS NUSE_Pipe_Receive(NUSE_PIPE pipe, U8 *message, U8 suspend);
Реализация чтения каналов в Nucleus SE
Вариант кода функции API NUSE_Pipe_Receive() (после проверки параметров) выбирается условной компиляцией в зависимости от того, активирована ли поддержка API вызовов блокировки (приостановки задач) или нет. Мы рассмотрим оба варианта ниже.
Если блокировка отключена, код этого вызова API довольно прост:
Если блокировка задач активирована, код становится более сложным:
Некоторые пояснения могут быть полезны.
Код заключен в цикл do…while, который выполняется, пока параметр приостановки задач имеет значение NUSE_SUSPEND.
Запись в начало канала
Служебный вызов Nucleus RTOS API для записи в начало канала очень гибкий, что позволяет приостанавливать задачи неявным образом или с таймаутом, если операцию нельзя завершить немедленно (например, при попытке записи в полный канал). Nucleus SE имеет аналогичный служебный вызов, но приостановка задач опциональна, а таймаут не реализован.
Вызов для записи в начало канала в Nucleus RTOS
Прототип служебного вызова:
STATUS NU_Send_To_Front_Of_Pipe(NU_PIPE *pipe, VOID *message, UNSIGNED size, UNSIGINED suspend);
Вызов для записи в начало канала в Nucleus SE
Этот служебный вызов поддерживает основной функционал Nucleus RTOS API.
Прототип служебного вызова:
STATUS NUSE_Pipe_Jam(NUSE_PIPE pipe, ADDR *message, U8 suspend);
Реализация записи в начало канала в Nucleus SE
Вариант кода функции NUSE_Pipe_Jam() очень похож на NUSE_Pipe_Send(), кроме того, что для хранения в нем данных используется индекс NUSE_Pipe_Tail[], следовательно:
В следующей статье будем рассматривать дополнительные служебные вызовы, связанные с каналами, а также соответствующие структуры данных.
Подключение к провайдерам баз данных Microsoft SQL Server, Oracle, MySQL Server
1. Выберите одну из перечисленных опций и нажмите кнопку Далее.
2. Укажите имя сервера, имя пользователя и пароль
3. Выберите из списка базу данных с которой вы хотите работать. Из этой базы программа в дальнейшем считает данные.
4. Просмотр таблиц выбранной базы данных.
5. Введите имя подключения к базе данных и нажмите на кнопку Завершить.
Подключение к Microsoft Access, Microsoft Excel, DBASE и текстовым файлам.
1. На первой странице мастера выберите одну из опций.
2. Появиться дополнительное окно, в котором можно выбрать файл. Выберите файл с соответствующим расширением и нажмите на кнопку Open / Открыть.
3. В поле Название файла появится путь к выбранному файлу базы данных.
Если вы хотите выбрать другой файл, то нажмите на кнопку . .
4. На этом шаге вы можете просмотреть таблицы с данными принадлежащие выбранному файлу.
5. Введите имя подключения к базе данных и нажмите на кнопку Завершить.
Подключение к другим источникам данных
1. На первой странице мастера выберите последнюю опцию.
2. Появится окно Свойства канала передачи данных. Выберите необходимый провайдер и нажмите на кнопку Далее.
3. На вкладке Соединение нужно установить подключение к выбранной базе данных.
Установите флажок Сохранять пароль
Нажмите на кнопку Проверить подключение. Если подключение выпонилось удачно, нажмите на кнопку OK.
Нажмите на кнопку Ok чтобы закрыть окно Свойства канала передачи данных.
Строка подключения появится в окне мастера. Чтобы выбрать другое соединение, нажмите на кнопку Мастер.
Просмотр таблиц выбранной базы данных.
Введите имя подключения к базе данных и нажмите на кнопку Завершить.
Тем, кто стремится разобраться в сетях и протоколах, посвящается.
В статье рассматриваются основы надежной передачи данных, реализуются примеры на Go, в том числе UDP и TCP . По мотивам раз, два, три и книги "Компьютерные сети. Нисходящий подход", а то все обсуждают только Танненбаума и Олиферов.
Протокол транспортного уровня
Обеспечивает логическое соединение между прикладными процессами, выполняющимися на разных хостах. Логическое соединение с точки зрения приложений выглядит как канал, непосредственно соединяющий процессы.
Протоколы транспортного уровня поддерживаются конечными системами, но не сетевыми маршрутизаторами (кроме — DPI). На стороне отправителя транспортный уровень преобразует данные прикладного уровня, которые получает от передающего прикладного процесса, в пакеты транспортного уровня, называемые сегментами.
Далее транспортный уровень передает сегмент сетевому уровню отправителя, где сегмент инкапсулируется в пакет сетевого уровня (дейтаграмму) и отсылается. На принимающей стороне сетевой уровень извлекает сегмент транспортного уровня из дейтаграммы и передает его вверх транспортному уровню. Далее транспортный уровень обрабатывает полученный сегмент таким образом, чтобы его данные стали доступны приложению-получателю.
Принципы надежной передачи данных
Надежная передача данных по совершенно надежному каналу
Простейший случай. Отправляющая сторона просто принимает данные от верхнего уровня, создает содержащий их пакет и отправляет его в канал.
Надежная передача данных по каналу с возможными ошибками
Следующим этап — это предположение, что все переданные пакеты получены в том порядке, в котором они были отправлены, но биты в них могут быть повреждены, в связи с тем, что канал иногда передает данные с искажениями.
В таком случае применяются механизмы:
- обнаружения ошибки;
- обратной связи;
- повторной передачи.
Протоколы надежной передачи данных, обладающие подобными механизмами многократного повторения передачи, называются протоколами с автоматическим запросом повторной передачи (Automatic Repeat reQuest, ARQ).
Дополнительно, стоит предусмотреть возможность ошибок и в квитанциях, когда принимающая сторона не получит никакой информации о результатах передачи последнего пакета.
Решение этой задачи, используемое в том числе в TCP, состоит в добавлении в пакет данных нового поля, содержащего порядковый номер пакета.
Надежная передача данных по ненадежному каналу, допускающему искажение и потерю пакетов
Одновременно с искажениями, к сожалению, в сети присутствует потеря пакетов.
И для решения этой задачи требуются механизмы:
- определения факта потери пакетов;
- повторной доставки потерянных пакетов принимающей стороне.
Дополнительно, кроме потери пакета, необходимо предусмотреть возможность потери квитанции или, если ничего не потеряно, ее доставки со значительной задержкой. Во всех случаях производится одно и то же: повторная передача пакета. Для контролирования времени в данном механизме используется таймер отсчета, который позволяет определить окончание интервала ожидания. Так в пакете net параметр TCPKeepAlive установлен на 15 секунд по умолчанию:
Передающей стороне необходимо запускать таймер каждый раз при передаче пакета (как при первой, так и при повторной), обрабатывать прерывания от таймера и останавливать его.
Итак, мы ознакомились с ключевыми понятиями протоколов надежной передачи данных:
- контрольными суммами;
- порядковыми номерами пакетов;
- таймерами;
- положительными и отрицательными квитанциями.
Но и это не все!
Протокол надежной передачи данных с конвейеризацией
В том варианте, который мы уже рассмотрели, протокол надежной доставки очень неэфективен. Он начинает «тормозить» передачу, обеспечиваемую каналом связи, при увеличении RTT . Для повышения его эффективности, лучшей утилизации пропускной способности канала связи применяют конвейеризацию.
Применение конвейеризации приводит к:
- увеличению диапазона порядковых номеров, поскольку все отсылаемые пакеты (за исключением повторных передач) должны быть однозначно идентифицируемы;
- необходимости в увеличении буферов на передающей и принимающей сторонах.
Диапазон порядковых номеров и требования к размерам буферов зависят от действий, предпринимаемых протоколом в ответ на искажение, потерю и задержку пакета. В случае конвейеризации существуют два метода исправления ошибок:
- возвращение на N пакетов назад;
- выборочное повторение.
Возвращение на N пакетов назад — протокол скользящего окна
Отправитель должен поддерживать три типа событий:
Выборочное повторение
Когда размер окна и произведение пропускной способности на задержку распространения велики, в конвейере может находиться большое количество пакетов. В таком случае ошибка отдельного пакета может вызвать повторную передачу большого количества пакетов, большинство из которых не требовались.
Пример
Лучшие теоритические практики собраны в практической реализации TCP. А если кто-то знает, как лучше — welcome.
Читайте также: