Блютуз версия 3.0. Как выбрать Bluetooth-устройство для прослушивания музыки

Реляционная БД - это БД, основанная на реляционной модели данных (РМД).

В основе РМД лежит понятие отношения, или реляции (relation – отношение, англ., отсюда и происходит термин реляционные БД). Для работы с реляционными БД применяют реляционные СУБД. Использование реляционных баз данных было предложено доктором Коддом из компании IBM в 1970 году. Эти модели характеризуются простотой структуры данных, удобным для пользователя табличным представлением и возможностью использования формального аппарата алгебры отношений и реляционного исчисления для обработки данных.

В РМБД основной структурной единицей является таблица (отношение). Реляционная модель ориентирована на организацию данных в виде двумерных таблиц . Каждая реляционная таблица представляет собой двумерный массив и обладает следующими свойствами :

Каждый элемент таблицы – это один элемент данных;

Все столбцы в таблице однородные, т.е. все элементы в столбце имеют одинаковый тип (числовой, символьный и т.д.) и длину;

Каждый столбец имеет уникальное имя;

Одинаковые строки в таблице отсутствуют;

Порядок следования строк и столбцов может быть произвольным.

Отношения представлены в виде таблиц, строки которых соответствуют записям , а столбцы - атрибутам отношений, доменам, полям. Каждая строка хранит данные об одном объекте, а каждое поле характеризует один из параметров объекта. Каждая таблица должна иметь уникальное название БД.

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

32 Основные модели баз данных (БД)

БД – структурированный набор сведений, относящихся к одной предметной области или нескольким родственным областям. Все существующие БД могут строиться на различных принципах, которые характеризуются понятием модель БД.

Модель БД определяет способ связи между объектами в базе, способ хранения информации на носителе (в памяти компьютера), способ извлечения и представления данных. Модели БД: 1)иерархическая, 2)сетевая, 3)реляционная.

1) Иерархическая (перв. пол. 60-х г.) предназначалась для хранения БД на бумажном носителе и магнитных лентах. Структура связи между данными основ-ся на теории Графа и предст-ся в виде дерева (перевернутого). Разл. объекты создают узлы дерева , т.е. находятся на разл. уровнях иерархии. Связи опис-ся в категориях отец-сын или предок-потомок. Каждый узел i-го уровня иерархии относитсяся к узлу i-1 уровня (i>1), как относится сын к отцу, либо отец к сыну, а именно сын может быть одного отца, а отец – одного и более сыновей, т.е. объект данного i-го уровня относится к объектам i+1 уровня, как 1 ко многим (1:N, 1:∞). Недостатки : 1) польз-ль должен знать структуру дерева, иначе поиск данных затруднен; 2) поиск необх. данных всегда нач-ся с корня, а дальше осущ-ся навигация по ветвям дерева.

2) Сетевая (втор. пол. 60-х г.) для уменьшить влияние недостатков предыдущей модели. Осн. отличие от иерархич.: может сущ-ть связь между объектами, находящ-ся как на одном уровне иерархии, так и на разных. Это привело к увел-ю скорости поиска данных. Однако сущ-т недостаток : польз-ль должен знать структуру такого дерева.

Основной недостаток двух моделей : очень слабая математическая база.

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

Реляционная компьютерная база, как и любая другая база, является ИС, схематически представленной:

СУБД (система управления БД) – специализированное программное средство (оболочка) или платформа, с помощью которой пользователь реализует все предусмотренные функции (операции) над данными. Функции: ввод (вставка), модификация (изменение), извлечение (селекция), удаление данных.

В ИСБД имеется важный компонент – администратор БД, который отвечает за сохранность и ценность данных, установление разл. прав доступа пользователя и т.д.

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

Здравствуйте.

3 декабря 2014 года Bluetooth SIG официально анонсировала спецификацию bluetooth версии 4.2.
В пресс-релизе указаны 3 главных нововведения:

• увеличение скорости приема-передачи данных;
• возможность подключения к интернету;
• улучшение конфиденциальности и безопасности.

Главный тезис пресс-релиза: версия 4.2 - идеальна для интернета вещей (IoT).
В этой статье я хочу рассказать, как реализованы эти 3 пункта. Кому интересно добро пожаловать.

Все, что описано ниже, относится только к BLE, поехали…

1. Увеличение скорости приема-передачи пользовательских данных.

Самым главным недостатком у BLE была малая скорость передачи данных. Хотя с какой стороны посмотреть, ведь изначально BLE придумывали ради сохранения энергии источника, питающего устройство. А чтобы беречь энергию, надо с перерывами выходить на связь и передавать немного данных. Однако, все равно, весь интернет заполнен возмущениями о малой скорости и вопросами о возможности ее увеличения, а также увеличения размера передаваемых данных.

И вот с появлением версии 4.2, Bluetooth SIG заявил об увеличении скорости передачи в 2,5 раза и размера передаваемого пакета в 10 раз. Как же они этого добились?

Сражу скажу, что эти 2 цифры связаны друг с другом, а именно: скорость увеличилась потому, что увеличился размер передаваемого пакета.

Посмотрим на PDU (protocol data unit) канала данных:


Каждый PDU содержит 16-ти битный заголовок (header). Так вот, этот заголовок в версии 4.2 отличается от заголовка в версии 4.1.

Вот заголовок версии 4.1:

А вот заголовок версии 4.2:

Примечание: RFU (Reserved for Future Use) - поле, обозначенное этой аббревиатурой зарезервировано для будущего использования и заполняется нулями.

Как мы видим, последние 8 бит заголовка отличаются. Поле «Length» - это сумма длин полезных данных и поля MIC (Message Integrity Check), находящегося в PDU (если последнее включено).
Если в версии 4.1 поле «Length» имеет размер 5 бит, то в версии 4.2 это поле размером 8 бит.

Отсюда несложно вычислить, что поле «Length» в версии 4.1 может содержать значения в промежутке от 0 до 31, а в версии 4.2 в промежутке от 0 до 255. Если из максимальных значений вычесть длину поля MIC (4 октета), то получим, что полезных данных может быть 27 и 251 октет для версии 4.1 и 4.2 соответственно. На самом деле максимальное кол-во данных еще меньше, т.к. в полезной нагрузке находятся еще и служебные данные L2CAP (4 октета) и ATT (3 октета), но это мы рассматривать не будем.

Таким образом размер передаваемых пользовательских данных увеличился приблизительно в 10 раз. Что же касается скорости, которая, почему-то, увеличилась не в 10 раз, а всего в 2.5 раза, то тут нельзя говорить о пропорциональном увеличении, потому, что все упирается еще и в гарантированность доставки данных, ведь гарантировать доставку 200 байт немного сложнее чем 20-ти.

2. Возможность подключения к интернету.

Пожалуй, самое интересное нововведение, из-за которого Bluetooth SIG и объявила, что версия 4.2 делает интернет вещей (IoT) лучше именно благодаря этой возможности.

Еще в версии 4.1 в L2CAP появился режим «LE Credit Based Flow Control Mode». Этот режим позволяет управлять потоком данных, используя т.н. схему, основанную на кредите. Особенность схемы в том, что она не использует сигнальные пакеты, для обозначения кол-ва передаваемых данных, а запрашивает у другого устройства кредит на определенный объем данных для передачи, тем самым ускоряя процесс передачи. При этом, принимающая сторона каждый раз при получении фрейма, уменьшает счетчик фреймов, и при достижении последнего фрейма может разорвать соединение.

В списке команд L2CAP появилось 3 новых кода:
- LE Credit Based Connection request – запрос на соединение по схеме кредита;
- LE Credit Based Connection response – ответ на соединение по схеме кредита;
- LE Flow Control Credit – сообщение о возможности получить дополнительные LE-кадры.

В пакете «LE Credit Based Connection request»


есть поле «Initial Credits» длиной в 2 октета, указывающее на кол-во LE-фреймов, которое устройство может отправить на уровне L2CAP.

В ответном пакете «LE Credit Based Connection response»


в том же поле указано кол-во LE-фреймов, которое может отправить другое устройство, а также в поле «Result» указан результат запроса на соединение. Значение 0x0000 говорит об успехе, остальные значения указывают на ошибку. В частности, значение 0x0004 указывает на отказ в соединении из-за отсутствия ресурсов.

Таким образом уже в версии 4.1 появилась возможность передачи большого кол-ва данных на уровне L2CAP.
И вот, практически одновременно с выходом версии 4.2, публикуется:

• сервис: «IP Support Service» (IPSS) .
• профиль IPSP (Internet Protocol Support Profile) , который определяет поддержку передачи пакетов IPv6 между устройствами, имеющими BLE.

Главным требованием профиля для уровня L2CAP является «LE Credit Based Connection» появившееся в версии 4.1, которое, в свою очередь позволяет передавать пакеты с MTU >= 1280 октетов (надеюсь намек на цифру понятен).

Профиль определяет следующие роли:
- роль маршрутизатора (Router) – используется для устройств, которые могут маршрутизировать IPv6 пакеты;
- роль узла (Node) – используется для устройств, которые могу только принимать или отправлять пакеты IPv6; имеют функцию обнаружения сервисов и имеют сервис IPSS, позволяющий маршрутизаторам обнаруживать данное устройство;

Устройства с ролью маршрутизатора, которым необходимо подключение к другому маршрутизатору могут иметь роль узла.

Как ни странно, но передача пакетов IPv6 не является частью спецификации профиля, и указывается в IETF RFC «Transmission of IPv6 packets over Bluetooth Low Energy» . В этом документе опредлен еще один интересный момент, а именно то, что при передаче пакетов IPv6 используется стандарт 6LoWPAN - это стандарт взаимодействия по протоколу IPv6 поверх маломощных беспроводных персональных сетей стандарта IEE 802.15.4.

Посмотрите на рисунок:


В профиле определено, что IPSS, GATT и ATT используются только для обнаружения сервиса, а GAP используется только для обнаружения устройства и установки соединения.

А вот выделенное красным, как раз говорит о том, что передача пакетов не входит в спецификацию профиля. Это позволяет программисту написать свою реализацию передачи пакетов.

3. Улучшение конфиденциальности и безопасности.

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

• обмен информацией о способах сопряжения;
• генерация краткосрочных ключей (Short Term Key (STK));
• обмен ключами.

В версии 4.2 2-я фаза разделилась на 2 части:

• генерация краткосрочных ключей (Short Term Key (STK)) под названием «LE legacy pairing»
• генерация долговременных ключей (Long Term Key (LTK)) под названием «LE Secure Connections»

А 1-я фаза добавилась еще одним способом сопряжения: «Numeric Comparison» который работает только со вторым вариантом 2-й фазы: «LE Secure Connections».

В связи с этим в криптографическом тулбоксе менеджера безопасности помимо 3-х существующих функций, появилось еще 5 и эти 5 используются только для обслуживания нового процесса сопряжения «LE Secure Connections». Эти функции генерируют:

• LTK и MacKey;
• подтверждающие переменные;
• переменные проверки аутентификации;
• 6-ти значные числа, используемые для отображения на связываемых устройствах.

Все функции используют алгоритм шифрования AES-CMAC с 128-ми битным ключом.

Так вот, если при сопряжении во 2-й фазе по методу «LE legacy pairing» генерировалось 2 ключа:

• Temporary Key (TK): 128-ми битный временный ключ, используемый для генерации STK;
• Short Term Key (STK): 128-ми битный временный ключ, используемый для шифрования соединениЯ

то по методу «LE Secure Connections» генерируется 1 ключ:

• Long Term Key (LTK): 128-ми битный ключ, используемый для шифрования последующих соединениЙ.

Результатом этого нововведения мы получили:

• предотвращение отслеживания, т.к. теперь за счет «Numeric Comparison» есть возможность контролировать возможность подключения к Вашему устройству.
• улучшение энерго-эффективности, т.к. теперь не требуется дополнительная энергия для повторных генераций ключей при каждом соединении.
• отраслевой стандарт шифрования для обеспечения конфиденциальных данных.

Как это ни странно звучит, но за счет улучшения безопасности мы получили улучшение энерго-эффективности.

4. Есть ли уже возможность пощупать?

Да, есть.
NORDIC Semiconductor выпустил «nRF51 IoT SDK» который включает в себя стек, библиотеки, примеры и API для устройств серии nRF51. Сюда входят:

• чипы nRF51822 и nRF51422;
• nRF51 DK;
• nRF51 Dongle;
• nRF51822 EK.

По