Replies (35)

  • @agr, Не сочти за наезд, но чот бенчмарков овердохера и сложно в итоге за деревьям лес разглядеть, может лучше какое-то саммари в ридми, а подробности в отд. файлик?
  • @agr, Ну и у тебяж там нет защиты от уязвимости hashable, да? (ща чот нет времени код расковырять толком)
  • @qrilka, коллизии, в смысле? или что?
  • @qrilka, нарисуем
  • @agr, да, коллизии, "задокументированная" фича либы
  • @qrilka, это учтено
  • @agr, А может ткнёшь тупого пальцем, в insert вижу O(n)
  • @agr, @agr Что-то вы странное там меряете. Hashable, но в бенчах сплошные инты.

    Даёшь хотя бы мап /usr/share/dict/word на uuid и обратно.

    (PRs welcome, я знаю, но всё же. Вдруг это тоже бай дизайн.)
  • @qrilka, если совпадения по хэшу нет, addOrResize (L297)
  • @agr, а если есть — смотри ветку выше
  • @Anonymous, + за PR. сейчас в дискурсе на тему knucleotids бенчмарка речь зашла.
  • @agr, так-то я уверен, что проблемы ещё есть, и надо их решать.
  • @agr, чот я не проснулся ещё. если совпадения по хэшу нет, то идёт выборка следующего элемента в бакете, что как бы не O(1), но и не O(n). но фишка ещё и в том, что выборка бакета производится по хэшу и длине массива. т.е. чаще всего будет встречаться -1, а значит, addOrResize.
  • @agr, у тебя в посте chaining и order addressing, в хаддоках это даж не упоминается, но в любом случае ни один из методов от DoS-атаки не защищает
  • @qrilka, ну и интересно было видеть твой анонс параллельно с тем, что я пост Сида ревьюил — cs-syd.eu
  • @qrilka, ок, хаддоки я поправлю
  • @qrilka, интересная точка зрения там, но нападающему нужно заранее знать, что сервер хаскельный
  • @agr, ну ты сам понимаешь, что security by obscurity так себе подход
  • @qrilka, тоже верно
  • @qrilka, Сервер хаскельный, он один и не включена рандомизация в hashable, не ограничен размер payload, а если у вас 1 инстанс в продакшене, то у вас уже большие проблемы чем DDoS
  • @qnikst, А ещё идея собирать мапу во время Парсинга кажется порочной сама по себе, какая бы мапа не была
  • @qnikst, Идея о том, что все хешмапы должны быть collision free тоже
  • @qnikst, ну т.е. ты про то, что aeson нельзя использовать?
  • @qnikst, тут не надо второй D в DoS, наличие более одного инстанса особо ситуацию же не меняет
  • @qrilka, Да, на мой взгляд использование aeson для разбора json в веб сервисах это не лучшая идея. Проблема в том, что прямо готовых библиотек, которые во всём лучше нет
  • @qrilka, Как же, на всех разные случайные константы хэширования, ты во-первых фиг поберёшь значения, при которых происходят коллизии, во вторых, если и подберёшь, то положишь макисимум 1 инстанс
  • @qnikst, здрасьте, ну стоит у тебя балансер, за ним, ну 7 инстансов, запулю я 500 запросов с таким жсоном и жрать цпу будут все 7
  • @qnikst, "во всём" как-то уж максималистски, возможно как-то балансировать риски
  • @qrilka, У всех разные константы, с чего это все тупить будут?
  • @qnikst, ты пишешь "рандомизация не включена" и, если 1 инстанс, то уже проблемы, якобы просто наличие более 1 инстанса поможет, а теперь пишешь, что константы разные?
  • @qrilka, ты уж определись, или более одного инстанса решает проблему, или всёж речь про рандомизацию
  • @qrilka, несколько интстансов + рандомизация решают проблему.
  • @qnikst, ну 1 инстанс эт, конечно, стрёмновато, но именно от этой проблемы достаточно и тупо рандомизации
  • @qrilka, Мне показалось, что теоретики на реддисе утверждают, что по ответам с одного инстанса они смогут подобрать константы и как результат в каких значениях будут коллизии. А несколько инстансов эту теоритическую возможноть убирают
  • @qnikst, не ходок в реддит, может и утверждают, но несколько инстансов по-моему усложняют, но совсем-то не убирают возможность, если она есть, конечно