Вести с полей
В процессе установки FB3 на тестовый сервер, обнаружил что он там когда-то уже пытался прижиться…
Задумался… Четыре года прошло, ёлки-палки.
Про C++
Привет всем.
Полез в код Firebird (не напрягайтесь), чтобы посмотреть одну штуку.
Увидев код:
(Arg::Gds(isc_auth_datalength) <<Arg::Num(charSize) <<Arg::Num(RemotePassword::SRP_SALT_SIZE * 2) <<"salt").raise();
Завис, а потом долго не мог вспомнить — «… зачем я сюда пришел?». А, ну да, полотенце жеж.
Забавно осознавать что я подобные конструкции игнорировал раньше. Наверное срабатывал защитный механизм.
Не, не круто. Надо так:
Arg::Gds(isc_auth_datalength) <<Arg::Num(charSize) <<Arg::Num(RemotePassword::SRP_SALT_SIZE * 2) <<"salt" <<raise;
А еще круче:
Arg::Gds(isc_auth_datalength) <<Arg::Num(charSize) <<Arg::Num(RemotePassword::SRP_SALT_SIZE * 2) <<"salt" <<raise_me;
Где raise_me это манипулятор, который перемещает (не копирует) состояние сконструированного объекта в выкидываемый объект исключения.
Пошел искать дальше искать, где эта зараза приводит имя пользователя к верхнему регистру.
Релиз IBProvider v3.32
Привет всем.
30 сентября были выложены бинарники нового релиза IBProvider-а. Сегодня выложили новости.
Основное — исправлена ошибка с блобами. Забавно, что несмотря на огромное количество тестов и внутренних проверок, эта бага прожила больше 6 лет и вылезла у клиента. В восемь вечера пришло письмо, в два часа ночи клиент получил исправленную и (номинально) оттестированную сборку. Чуть позже были созданы расширенные тесты и выложены релизные бинарники.
В общем, поупражнялся в поддержке.
Комбинаторика …
Привет всем.
В FB3 (13-протокол) сделали «упакованную» передачу для NULL-индикаторов. Раньше каждый индикатор передавался по-отдельности как SHORT-значение. Теперь все индикаторы передаются через битовый массив.
Ну ладно, реализовал этот формат. Теперь надо бы это все проверить. Желательно — через перебор максимально доступного диапазона.
Исходные данные — у нас F колонок, из них N с NULL-значениями.
(далее…)
Про отмену операций в Firebird (#2)
Привет всем.
Некоторое время назад, при прогоне тестов (с использованием пула подключений) на FB3, увидел интересный эффект — отмена операций в одном тесте может прерывать выполнение операций в следующем тесте.
Поставил я у себя в голове галочку, что на FB2.5 такого не было, и забил на эту проблему.
А сейчас вот увидел аналогичную проблему в рамках одного теста и на FB2.5 — мы вроде как хотим отменить Execute, а внезапно отменяется Commit:
[THR:010600] [test] RemoteFB__Connector::ConnectToDatabase ...OK [THR:010600] [test] RemoteFB__Connector::StartTransaction ...OK [THR:010600] [test] RemoteFB__Connector::StmtAllocate ...OK [THR:010600] [test] RemoteFB__Connector::StmtPrepare ...OK [THR:010600] [test] Run thread [THR:004068] [thread] Execute command [THR:010600] [test] Wait 1 sec [THR:010600] [test] Cancel [THR:010600] [test] Wait Thread [THR:004068] [thread] RemoteFB__Connector::StmtExecute ...OK [THR:010600] [test] Thread was stopped [THR:010600] ERROR: [test] We wait the cancel exception! [THR:010600] [test] RemoteFB__Connector::StmtDrop ...OK [THR:010600] [test] RemoteFB__Connector::Commit ... FAILED [THR:010600] ERROR: [RemoteFB.WORK.Cancel.01.StmtExecute.ptype__lazy_send] [Firebird] Операция была отменена.
Лопата в том, что:
1. Провайдер (и его собственный FB-клиент), отдает серверу Cancel-команду пока выполняется Execute. Про это было в предыдущем опусе со следующим примером.
2. В конце концов, тест (поток 010600) сначала выполняет Cancel, а потом Commit.
Вот такая вот засада с этим Cancel, которая (по факту) делает эту фичу бестолковой игрушкой. Сделанной для галочки.
Про списки объектов
Привет всем.
В потрохах Firebird многие вещи организованы в списки. Однонаправленные. Других я там не встречал. Ну организованы, так организованы. Вообщем-то, это их личные проблемы, которые снаружи не парят до определенного момента.
В процессе натягивания существующих тестов, созданных для собственного клиента FB (10-12 протоколы), на клиента для FB3 (13-ый протокол), задрался ждать пока завершится ничем неприметный тест. Полчаса работал. Полез в лог: в цикле три раза подряд создается/подготавливается/освобождается группа из 64999 запросов.
[THR:012440] [18.09.2016 10:44:40] *********************************************** [THR:012440] [18.09.2016 10:44:40] * START TEST [RemoteFB.WORK.013.StmtAllocate.v2.ptype__lazy_send.011.check_release_of_dropped_stmts] [THR:012440] [18.09.2016 10:44:40] * [THR:012440] [18.09.2016 10:44:40] [test] Hello from test! [THR:012440] [18.09.2016 10:44:40] [test] RemoteFB__Connector::ConnectToDatabase ...OK [THR:012440] [18.09.2016 10:44:40] [test] RemoteFB__Connector::StartTransaction ...OK [THR:012440] [18.09.2016 10:44:40] [test] Allocate statements ... [THR:012440] [18.09.2016 10:46:31] [test] OK. We got the error. [THR:012440] [18.09.2016 10:46:31] [test] 1. [Firebird] too many open handles to database [THR:012440] [18.09.2016 10:46:31] [test] 2. [LCPI.IBProvider.3] [Подсистема: remote_fb.p13] Ошибка инициализации дескриптора запроса. [THR:012440] [18.09.2016 10:46:31] [test] nMaxStatements: 64999 [THR:012440] [18.09.2016 10:46:32] [test] RemoteFB__Connector::ConnectToDatabase ...OK [THR:012440] [18.09.2016 10:46:32] [test] RemoteFB__Connector::StartTransaction ...OK [THR:012440] [18.09.2016 10:46:32] [test] -------------------------------- pass: 1 [THR:012440] [18.09.2016 10:46:32] [test] Allocate statements ... [THR:012440] [18.09.2016 10:46:32] [test] ---- [THR:012440] [18.09.2016 10:48:37] [test] Drop statements ... [THR:012440] [18.09.2016 10:48:37] [test] -------------------------------- pass: 2 [THR:012440] [18.09.2016 10:48:37] [test] Allocate statements ... [THR:012440] [18.09.2016 10:56:57] [test] ---- [THR:012440] [18.09.2016 10:58:49] [test] Drop statements ... [THR:012440] [18.09.2016 10:58:49] [test] -------------------------------- pass: 3 [THR:012440] [18.09.2016 10:58:49] [test] Allocate statements ... [THR:012440] [18.09.2016 11:10:01] [test] ---- [THR:012440] [18.09.2016 11:11:51] [test] Drop statements ... [THR:012440] [18.09.2016 11:11:51] [test] RemoteFB__Connector::Commit ...OK [THR:012440] [18.09.2016 11:14:24] [test] RemoteFB__Connector::DetachDatabase ...OK [THR:012440] [18.09.2016 11:14:24] * [THR:012440] [18.09.2016 11:14:24] * REAL TIME:17845270915 [00:29:44.5270915] [THR:012440] [18.09.2016 11:14:24] * USER TIME:155844999 [00:00:15.5844999] [THR:012440] [18.09.2016 11:14:24] * KERNEL TIME:82524529 [00:00:08.2524529] [THR:012440] [18.09.2016 11:14:24] * TOTAL TIME:238369528 [00:00:23.8369528] [THR:012440] [18.09.2016 11:14:24] * [THR:012440] [18.09.2016 11:14:24] * STOP TEST [RemoteFB.WORK.013.StmtAllocate.v2.ptype__lazy_send.011.check_release_of_dropped_stmts]
А, ну да… Однонаправленный список объектов запросов.
Где-то год назад меня эта однонаправленность конкретно задолбала и пришлось выписать серверу лекарство — двунаправленный список, который гарантирует фиксированное время удаления элементов.
Наверное надо будет в свою тройку его тоже залить. Потому что FB2.5 (такой же отладочный как и тройка) с этим исправлением работает в два раза быстрее:
[THR:013768] [18.09.2016 11:19:07] *********************************************** [THR:013768] [18.09.2016 11:19:07] * START TEST [RemoteFB.WORK.013.StmtAllocate.v2.ptype__lazy_send.011.check_release_of_dropped_stmts] [THR:013768] [18.09.2016 11:19:07] * [THR:013768] [18.09.2016 11:19:07] [test] Hello from test! [THR:013768] [18.09.2016 11:19:09] [test] RemoteFB__Connector::ConnectToDatabase ...OK [THR:013768] [18.09.2016 11:19:09] [test] RemoteFB__Connector::StartTransaction ...OK [THR:013768] [18.09.2016 11:19:09] [test] Allocate statements ... [THR:013768] [18.09.2016 11:21:38] [test] OK. We got the error. [THR:013768] [18.09.2016 11:21:38] [test] 1. [Firebird] too many open handles to database [THR:013768] [18.09.2016 11:21:38] [test] 2. [LCPI.IBProvider.3] [Подсистема: remote_fb.p12] Ошибка инициализации дескриптора запроса. [THR:013768] [18.09.2016 11:21:38] [test] nMaxStatements: 64999 [THR:013768] [18.09.2016 11:22:06] [test] RemoteFB__Connector::ConnectToDatabase ...OK [THR:013768] [18.09.2016 11:22:06] [test] RemoteFB__Connector::StartTransaction ...OK [THR:013768] [18.09.2016 11:22:06] [test] -------------------------------- pass: 1 [THR:013768] [18.09.2016 11:22:06] [test] Allocate statements ... [THR:013768] [18.09.2016 11:22:06] [test] ---- [THR:013768] [18.09.2016 11:24:37] [test] Drop statements ... [THR:013768] [18.09.2016 11:24:37] [test] -------------------------------- pass: 2 [THR:013768] [18.09.2016 11:24:37] [test] Allocate statements ... [THR:013768] [18.09.2016 11:26:27] [test] ---- [THR:013768] [18.09.2016 11:28:56] [test] Drop statements ... [THR:013768] [18.09.2016 11:28:56] [test] -------------------------------- pass: 3 [THR:013768] [18.09.2016 11:28:56] [test] Allocate statements ... [THR:013768] [18.09.2016 11:30:47] [test] ---- [THR:013768] [18.09.2016 11:33:16] [test] Drop statements ... [THR:013768] [18.09.2016 11:33:16] [test] RemoteFB__Connector::Commit ...OK [THR:013768] [18.09.2016 11:33:50] [test] RemoteFB__Connector::DetachDatabase ...OK [THR:013768] [18.09.2016 11:33:50] * [THR:013768] [18.09.2016 11:33:50] * REAL TIME:8831512364 [00:14:43.1512364] [THR:013768] [18.09.2016 11:33:50] * USER TIME:134316861 [00:00:13.4316861] [THR:013768] [18.09.2016 11:33:50] * KERNEL TIME:131352842 [00:00:13.1352842] [THR:013768] [18.09.2016 11:33:50] * TOTAL TIME:265669703 [00:00:26.5669703] [THR:013768] [18.09.2016 11:33:50] * [THR:013768] [18.09.2016 11:33:50] * STOP TEST [RemoteFB.WORK.013.StmtAllocate.v2.ptype__lazy_send.011.check_release_of_dropped_stmts]
Но это надо раз десять тест запустить, чтобы созреть для такого подвига.
Are you prepared for Firebird 3?
Привет всем!
Увидел сегодня %subj% на firebirdnews.
Задумался…
А ведь пять лет прошло, Карл. Пять лет!
FB3, DatabaseParameterBuffer
Привет всем.
Меня тут мысль одна посетила (и ей одиноко …).
В тройке (а может и раньше, не разбирался) появилась новая версия формата буфера с параметрами подключения к базе данных — v2. В отличии от v1, в v2 можно передавать параметры с длиной вплоть до 65535 байт. В v1 длина ограничивалась 255 байтами.
Если мы подключаемся к серверу через fbclient.dll, то при выборе формата DPB мы можем опираться на версию серверного клиента.
Однако что-то я не узрел в новой fbclient.dll кода преобразования v2->v1 для случая подключения к Firebird с версией младше третьей.
Наверное плохо искал.
Но если его там действительно нет, то вторая версия DPB идет лесом. И, при работе с сервером через fbclient.dll, надо продолжать сидеть на DPB v1.
——
При подключении к серверу минуя fbclient.dll, DPB можно сформировать после определения версии протокола. Что, собственно говоря, и делается в IBProvider. И FB3 (13-ый протокол) действительно может принимать DPB v2.
FB3, Win_SSPI, Wire_Crypt=disabled
С пятницей всех.
Продолжая воспроизводить функциональность fbclient.dll (v3) в собственном клиенте для FB3, обнаружил следующие ну очень интересные вещи для SSPI-аутентификации:
При подключении с разрешенным шифрованием трафика (Wire_Crypt=enabled) обмен сообщениями с сервером на этапе инициализации выглядит так:
PROTOCOL: XDR_ENCODE (0) - op_connect (1) PROTOCOL: XDR_DECODE (1) - op_cond_accept (98) PROTOCOL: XDR_ENCODE (0) - op_cont_auth (92) PROTOCOL: XDR_FREE (2) - op_cont_auth (92) PROTOCOL: XDR_DECODE (1) - op_response (9) PROTOCOL: XDR_ENCODE (0) - op_attach (19) PROTOCOL: XDR_DECODE (1) - op_response (9)
А с выключенным шифрованием трафика (Wire_Crypt=disabled) вот так:
PROTOCOL: XDR_ENCODE (0) - op_connect (1) PROTOCOL: XDR_DECODE (1) - op_accept_data (94) PROTOCOL: XDR_ENCODE (0) - op_attach (19) PROTOCOL: XDR_DECODE (1) - op_response (9)
Возникла мысль — куда делась передача данных из третьей строки первого варианта?
Оказалось, во втором случае это делается через op_attach и его DatabaseParameterBuffer (DPB).
В целом, эта два разных способа достижения одного результата — «трафик без шифрования». Шифрование для Win_SSPI собственными средствами сервера и клиента, насколько я понимаю, не поддерживается.
Попытка привести второй вариант к первому, то есть вместо передачи данных через DPB отправлять отдельный пакет (op_cont_auth), не работает — сервер возвращает ошибку «unavailable database».
Собственно говоря, раздражает тот факт, что похоже придется размазывать код аутентификации между op_connect (подключение к серверу) и op_attach (подключение к базе).
А ведь по-началу даже начинало казаться, что новый механизм авторизации тринадцатого протокола выглядит вполне логичным и предсказуемым.
Ан нет.
В следующий раз, когда начнет казаться, сразу начну креститься.
Триал IBProvider v3.32.0 [сборка 21686]
Привет всем.
На сайт провайдера загружен новый триал, в котором появилось новое свойство инициализации — «remote:protocol». Оно относится к конфигурации встроенного клиента и позволяет задавать версию протокола соединения.
В реальной работе это свойство и пара других свойств («remote:protocol_arch», «remote:protocol_type») не нужны. Но вот для создания тестов и всякого рода глумлений экспериментов над сервером — они весьма кстати.