GDB позволяет вводить команды из файла

Приведу несколько примеров. Поставить breakpoint с условием:

> cat 1.gdb

break my_func if (var > 10000)
commands
  print var
  info locals
  info registers
  backtrace
  continue
end

Поставить одноразовый catch на write syscall:

tcatch syscall write
commands
  printf "Syscall write\n"
  printf "File descriptor: %d\n", $rdi
  printf "Buffer: %p\n", $rsi
  printf "Bytes: %d\n", $rdx
  continue
end

Объявить функцию, которая принимает адрес и ставит условный watch на этот адрес:

define my_int_watch
  watch *(int*)$arg0 if *(int*)$arg0 % 3 == 0
  commands
    printf "New value: %d\n", *(int*)$arg0
    continue
  end
end

Реальные сценарии как правило чуть сложнее, т.к. дебаг символов может и не быть, условия посложнее, но для демонстрации идеи эти подходят.

Далее команды можно запустить из файла:

gdb -p 1234 -x 1.gdb

или прямо в cli:

> source 1.gdb

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

GDB также умеет в Python скрипты, но на питоняке я писал только pretty-printer'ы. Кто-то использовал python в gdb?

Если подумать, каких провалов я опасаюсь в работе, то это такой тип сбоев, в которых ваша торговая система набирает очень большую и нежелательную позицию. Она начинает неконтролируемо и быстро слать ордера на биржу, превышая заложенные в систему величины рисков. Такое произошло с Knight Capital (в блоге и на хабре на русском), что впоследствии привело к продаже фирмы. Всё произойдет за минуты или секунды, и уже после случившегося вы будете какое-то время только осознавать "эээ а что происходит". Либо, как вариант, баг в логике, неверные подсчёты или парсинг ответов приводит к тому, что подсчитанная позиция расходится с реальной. Вы думаете, у вас лонг на 100k, а у вас шорт на 100k, и рынок, зараза, идет вверх. Подобное случалось и со мной и с коллегами.

Второй неприятный тип сбоев: когда из-за бага торговая система простаивает. Представьте, что ваша, с любовью разработанная, фича остановила весь терминал, и фирма не зарабатывает, скажем, 5k в минуту, во всех рабочих чатах пишут ваше имя (а вы в отпуске). Понятно, что такая ситуация есть в других IT сферах, Crowdstrike подтвердит.

Третим в списке поставлю утечку приватных ключей и паролей (в результате небрежности или злого умысла сотрудников или внешней атаки). Вот вам любопытный случай c 3commas.

Предлагаю порассуждать, какие бы вы ввели механизмы, практики, правила в своем стартапе для защиты от подобных провалов? А точно хватит времени на это (в стартапе)? А точно не будет багов в самих механизмах защиты (если речь о коде)?

Что почитать по C++?

https://www.saminiir.com/lets-code-tcp-ip-stack-1-ethernet-arp/ - серия статей "Let's code a TCP/IP stack"

https://pthorpe92.dev/programming/systems/common-misunderstandings/ - серия статей "Common misunderstandings" по processes, tasks, async I/O.

https://eli.thegreenplace.net/2017/concurrent-servers-part-1-introduction/ - базовое "Concurrent servers" про select/epoll.

https://accu.org/journals/overload/32/182/teodorescu/ - базовый гайд про атомики "In an atomic world" от accu.

https://www.think-cell.com/en/career/devblog/cpp-needs-undefined-behavior-but-maybe-less - про UB и будущий erroneous behavior.

https://lemire.me/blog/2024/09/09/replace-stdstring-by-stdstring_view-when-you-can/ - один mega-string вместо кучи мелких от Daniel Lemire.

https://habr.com/ru/companies/pvs-studio/articles/846532/ - std::array не медленнее C-массива от PVS studio.

https://www.studyplan.dev/pro-cpp/concepts - серия доступных уроков по C++20 concepts, если еще не вкатились.

Что мне нравится в API крипто бирж:
— наличие batch запросов (несколько запросов отправляется одной пачкой)

— таймстемпы в микросекундах, а лучше даже в наносекундах (у некоторых только в миллисекундах, а встречались даже секунды)

— несколько таймстемпов из различных этапов ордера (время приема, время матчинга, время отправки отчета)

— когда можно задать окно, позже которого биржа не примет моё сообщение

— наличие запросов: order info, get open orders, cancel all, kill switch on disconnect

— в ответе есть request id и тип запроса

— api ключи с гранулярным доступом

— доки не устаревшие и не содержат банальных ошибок (редкость)

Не нравится:
— когда json ответа слишком глубокий: {"channel":"post","data":{"id":167248,"response":{"type":"action","payload":{"status":"ok","response":{"type":"cancel","data":{"statuses":["success"]}}}}}}

— когда ордербук передают через json объекты: "bids":[{"p":65332,"q":1.35},...], вместо массива массивов

— когда различные рынки (spot/perps) одной биржи делают разные команды (и появляются различия в api)

— когда выкатывают обновления в субботу

Интересная статья 2014 года, в которой автор пытается увидеть манипуляции на рынке через визуализацию ордербука во времени. К сожалению, картинки сжатые, но понять можно (прищурившись). Для новичков будет интересна первая часть, где объясняется принципы устройства ордербука, а для бывалых - вторая.

Интересно, что это происходило 10 лет назад, а все перечисленные паттерны до сих можно увидеть в ордербуках.

https://parasec.net/blog/order-book-visualisation/

Один криптобро решил сохранить свою seed фразу (12 слов по стандарту BIP-39) от кошелька на бумажке. Он схитрил и разделил последовательность посередине, записав первую часть на одну бумажкуу, оставшуюся - на другую, и спрятал их в разных местах.

К сожалению, злоумышленник нашел одну из бумажек, и теперь хочет перебрать недостающие 6 слов, чтобы забрать свой куш. Какое максимальное количество комбинаций ему может понадобиться перебирать?

hint #1: каждая позиция в фразе имеет 2048 возможных вариантов (слов), что составляет 11 бит энтропии

Решение задачи

Злоумышленник не знает, какую половинку он взял - левую или правую. По BIP-39 последние 4 бита последнего слова в фразе являются контрольной суммой. И контрольную сумму как вариант перебирать не нужно, её нужно вычислить. Поэтому мы должны рассмотреть две ветки:
- Если он нашел правую часть, тогда перебирать нужно левую часть. Каждое слово может быть одним из 2048 вариантов из специального словаря, или 2^11, а всего 6 слов, то есть 2^(11x6) = 2^66.
- Если он нашел левую часть, то перебирать надо меньше, т.к. биты контрольной суммы перебирать не нужно. Из 66 бит энтропии (66 это 11 бит на слово x 6 слов) мы вычитаем 4 бита чексуммы, получаем 62, то есть 2^62 варианта.

Т.к. ему нужно перебрать оба варианта, то суммируем числа, получаем 2^66 + 2^62 = 2^62 x (2^4 + 1) = 2^62 x 17 или 78398662313265594368.

Что не так с float'ом и спасет ли double?

По каким таким причинам биржи не уважают floating-point numbers? Смотришь в документацию, а они в json'ах цену и количество лотов шлют не number type, а string type.
Не {"price":36.12}, а {"price":"36.12"}.

Они так делают, если:
- практически: в их кодовой без используется какой-нибудь BigDecimal, который так сериализует числа.
- теоретически: они не могут гарантировать отсутствие чисел, непредставимых в double типе (например, 9007199254740993.0), даже, если сейчас такого не видно на горизонте. Проблема не в «маленьком диапазоне» double, а в невозможности точной двоичной репрезентации десятичных дробей.
- для некоторых полей такую гарантию они могут дать, и тогда они используют uint64 (сравни поля ts и v).
- они заботятся о пользователе, вводя проблему в сознательную область (т.к. теперь просто as_float() в парсере не вызовешь) и снижая вероятность ошибки.
- упрощают пользователю возможность прокинуть строку в свой кастомный парсер (не часть json либы).
- оставляют себе микро-возможность вписать пустую строку, либо "Nan" или "Inf" (и такое бывало).

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

Ладно, с биржами понятно. Допустим, прислали нам "amount":"36.12". В чем ваш trading engine будет это хранить? Это фундаментальный вопрос для торговой системы. Ни ужели точности double не хватит, ведь он может показывать числа от 2.22507e-308 до 1.79769e+308, что уже довольно дофига?

Как будто бы может и хватить, но все же легко наступить на грабли:
- Операции не ассоциативны: (a + b) + c может быть не равно a + (b + c).
- Различные платформы могут давать различные результаты операций.
- Ошибки округления накапливаются при последовательных математических операциях (см. 0.1 + 0.2).
- Сравнивать два floating-point числа напрямую чревато.
- Что-то еще наверянка забыл, дополните, плз.

Практический пример: вы посылаете торговый ордер на quantity 0.3, вам приходит три сделки по 0.1. Вы их складываете, чтобы понять полностью ли заполнен ордер, и тут вы и приехали, ибо:

(0.1 + 0.1 + 0.1) == 0.3 вычисляется в false

Да, вы можете сравнить числа через epsilon (abs(a-b) < eps), но потенциально легко где-то забыть вызвать правильную функцию. Что тогда, вон из профессии?

По итогу, используется либо double с дополнительными приседаниями (обвязками, проверками и т.п.), либо кастомный decimal тип (пример), либо изначально величины хранятся в самых мелких единицах (пример из Ethereum).

В декабре прошлого года я не продлил домен eyeleo.com для моего самого общественно-полезного проекта в жизни. Зашли посмотреть по ссылке? А зачем, домен то не продлён.

Где-то году в 2011-м в новогодние каникулы я написал Windows программу, напоминающую делать перерывы, чтобы глаза отдыхали от дисплея. Мне самому такая была нужна, а существующие вариации мне не нравились. EyeLeo была небольшой бесплатной программой, но делающей важное дело, поэтому она быстро стала весьма популярной, и долгое время я получал небольшой доход с донатов (через Adsense и Patreon). Однако из-за очень низкого качества кода и общей игрушечности, я буквально скрывал принадлежность к EyeLeo. Мне не хотелось, чтобы кто-то из коллег (или потенциальных работодателей) увидел код и сделал неверные выводы. Но сейчас решил: да пофиг, сделаю coming out. Программа-то полезная, и благодарных пользователей было много. Короче, это моя прога, и мне пофиг на качество кода, уже не стыдно.

Сейчас развивать её нет времени и желания (другие приоритеты), поэтому я перестал оплачивать домен. На Linux дистрибутивах сейчас есть Safe Eyes, и я рекомендую им пользоваться. Когда приходит время для перерыва, смотрите вдаль секунд на 20. И в долгосрочной перспективе это сильно поможет вам снизить нагрузку на зрение.

Чем из софтовых и физических решений для здоровья работников клавы и монитора вы пользуетесь?

Когда перешел в перспективный крипто HFT стартап...

(автор: KNADCORE)

⚡️Видео When Nanoseconds Matter: Ultrafast Trading Systems

Довольно интересная лекция от David Gross из Optiver о том, какие фишки используются в проектировании комплексных торговых систем:

- как лучше представить L3 ордербук в памяти, и как искать в нем.

- немного о проектировании и коде SPMC bounded очереди в shared memory.

- идея spawn'ить perf прямо из своего процесса.

- немного о likely/unlikely/cold секциях в коде.

- упомнянул о том, какой выигрыш даёт kernel bypass при работе с сетью.

- использование clang xray для добавления профилирования в рантайме.

Месяц-два назад начал изучать новый язык, чего не делал уже несколько лет. Предыдущим новым языком был Golang аж в 2018-м, но он меня не вштырил, хотя были приятные моменты и откровения.

Что за язык то?
Вы угадаете его с 2х слов: blazingly fast.
Подсказываю: 100% memory safe.

Правильно, это Ржавый.

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

Параллельно вникаю в Solana.