ты все думаешь, как его приспособить к балансировке нагрузки?
... Так уж устроен протокол, что одной только операции будет мало:
Вариант 1.
Как минимум, надо чтобы передавалась длина пакета. Сейчас смещение к началу следующего логического пакета, (в начале которого стоит код операции) надо довольно долго и мучительно вычислять. Особенно op_fetch.
При том, что содержимое самого fetch пакета совершенно неинтересно, и не нужно FBScanner-у. Но раз уже такое вычисление происходит, FBScanner подсчитывает кол-во прошедших строк. Которое нужно только для "красоты". Я уж молчу о том, что после того как FBScanner стал производить полную расшифровку протокола, нагрузка на CPU увеличилась на порядок.
(полная расшифровка появилась в версии FBScanner 2.5, без этого невозможно было понять, что происходит в 11ом протоколе FB2.1 и старше)
Но даже если так, то знание операции мало: стейтментов (или тр-ций) может быть несколько. Какому именно сейчас делается prepare - важно знать.
Вариант 2.
Интересно, а как сейчас происходит шифрация протокола? Полностью пакуется логический пакет?
Если да - то зачем? По сути, шифровать протокол нет никакого смысла.
Достаточно шифровать данные:
а) данные внутри fetch (каждый столбец - отдельно)
б) внутри передачи параметров (алгоритм тот же самый, как с fetch)
в) блобы
г) под вопросом - текст SQL запроса.
Если пойти по этому варианту, доработки в FBScanner будут ненужны
))
Пакеты не изменятся, а сами данные по барабану, в общем-то... правда, логирование всеравно накроется.