Спасибо за комментарий, идея действительно хорошая. Признаюсь, она мне в голову не приходила=)
Однако тут есть 2 фактора: 1) мы бы все равно не убрали проверку RC в валькирии потому что существует вероятность и 2) реализация потребует дополнительного поля в filedb, а для 12млрд записей это довольно прилично по памяти.
Все так. Максимальная вероятность такого события = p * 1/2^32, где p — вероятность ошибки при удалении. Если взять ее как 0.001(что явно много) то получается вероятность случайного удаления в таком случае ниже 2.3e-13. Но по факту она еще ниже, потому что в этой формуле не учитываются другие факторы, которые тоже уменьшают вероятность (например, что счетчик равен именно 2).
Также напомню что кроме этого уровня есть еще 3 уровня защиты от окончательной потери самого файла, но до них ни разу за 1.5 года не дошло (тфу-тфу) =)
Размер есть в индексах. Также, там есть crc по другому алгоритму, который при заборе тоже сверяется. Сам забор письма, собирание его из разных частей, сверка консистентности, форматирование и много чего реализовано в отдельной либе/сервисе. Это довольно обширный топик тоже, поэтому мы его не затрагиваем пока.
В общем, теоретическая возможность коллизии все же есть, однако она теоретическая, еще не встречалась и легко обнаруживается при доступе к «подмененному» файлу. Также напомню, что хеш соленый не известно чем, если даже известно — то это еще надо подобрать чтобы все сошлось=)
До заливки в это облачко файл лежит в письме, которое естественно есть целиком у сервиса, который хочет положить письмо в ящик (например, MX). Соответственно, имея все письмо целиком он легко считает хеш каждого из его партов и может дать его вместе с телом файла.
> Если файл удалять(уменьшать counter) после того как письмо успешно удалено
Это иллюзия. Если во время сброса dirtypages возникнет ошибка, либо допустим машина перезагрузится — письмо потом «удалится» еще раз. Эта ситуация по сути и есть «откат базы», мейджик защищает от нее в том числе.
> при удалении письма произошел сбой, то письмо останется без файла
В обычной ситуации — да, но не в нашем случае=) Дело в том, что декремент не завязан на само действие пользователя (удаление письма). Удалив письмо — пользователь и никто другой его больше не увидит. Однако двойной декремент прийти в теории может, вот именно этот риск и страхуется. Это если очень вкратце, на самом деле индексы писем — очень большая и важная подсистема почты, о ней я надеюсь сможем рассказать отдельно и более детально, там много интересностей.
1) Именно случайный magic дает защиту от декремента «чужой» единицы счетчика. Если он у всех одинаковый — то желаемый эффект не достигается.
2) Во-первых, хеши соленые, так что его нельзя угадать. Во-вторых, перебирать — этож сколько вариантов? В третьих — снаружи вообще нет интерфейса, позволяющего взять файл по хешу. Туда ходит только библиотека доступа к storage, и только она внутри себя знает как работать с этим хешом.
Я думаю ваш сотрудник не знал терминов «почтовый клиент» и «почтовый сервис». Он не делал вид, что между ними нет разницы, возможно потому что он просто не видит разницы.
Я конечно всячески приветствую просвещение масс, но вы должны знать: пользователя это все не волнует. У него свои проблемы, свои термины, о которых мы с вами не знаем и не хотим знать. А он просто хочет прочитать почту.
Другой пример: возможно, вы бы хотели воспользоваться другим сотовым оператором, не меняя номера телефона. В этом случае вас бы сильно волновало почему DEF-префикс не позволяет вам так вот просто это сделать?
Интересно, а если бы она ввела логин-пароль в Thunderbird — это тоже фишинг? А если вместо Thunderbird был бы некий сайт, который ведет себя так же как он?
В случае с SSL всё сложнее. Поддержка одного соединения весьма дорого обходится по памяти, даже если отключить сжатие: одно соединение обычно «кушает» не менее 32К памяти(и это оптимистичный вариант!), если взять 40тыс соединений это уже 1.2Гб памяти. Я бы сказал 100К и 1М — это пороги для SSL/не-SSL соответственно.
Вариант с прокси рассматривали, возможно она могла бы решить часть проблем, но конечно не все. Сделать первую версию на asio оказалось гораздо проще и быстрее, а сам переход решил многие вопросы. Поэтому нужда в прокси пока отпала и решили не усложнять админам жизнь.
Отвечу сразу вам и orcy. Признаться такой вариант в голову приходил, не на долго. Все-таки изначально сервер написан на C++ и логично было бы использовать библиотеки, которые что называется «ближе к телу». Наличие инкапсуляции также помогает выйти на некий уровень абстракции и не разбавлять код логики IMAP кодом управления событиями.
Насчет производительности — в этом посте взят пример http server 3 и просто собран «как есть». Способ обработки сами асинхронных событий в нём мне нравится, но вот остальной код кажется не слишком оптимальным. В частности, методы parse/consume в request_parser разбирает пришедшие данные побайтово, а все компоненты запроса кладёт в std::string по буквам, через push_back. Плюс, не учтена особенность strand, о которой говориться в этой статье. В подобных тестах нужно быть более осторожным=) Но конечно, спору нет: зачастую C++ библиотека будет работать медленнее plain-C. Я сторонник мнения, что лучше написать такие вещи быстрее, а сэкономленное время потратить на оптимизации самих алгоритмов, которые обычно «сьедают» больше ресурсов.
Однако тут есть 2 фактора: 1) мы бы все равно не убрали проверку RC в валькирии потому что существует вероятность и 2) реализация потребует дополнительного поля в filedb, а для 12млрд записей это довольно прилично по памяти.
Также напомню что кроме этого уровня есть еще 3 уровня защиты от окончательной потери самого файла, но до них ни разу за 1.5 года не дошло (тфу-тфу) =)
В общем, теоретическая возможность коллизии все же есть, однако она теоретическая, еще не встречалась и легко обнаруживается при доступе к «подмененному» файлу. Также напомню, что хеш соленый не известно чем, если даже известно — то это еще надо подобрать чтобы все сошлось=)
Это иллюзия. Если во время сброса dirtypages возникнет ошибка, либо допустим машина перезагрузится — письмо потом «удалится» еще раз. Эта ситуация по сути и есть «откат базы», мейджик защищает от нее в том числе.
> при удалении письма произошел сбой, то письмо останется без файла
В обычной ситуации — да, но не в нашем случае=) Дело в том, что декремент не завязан на само действие пользователя (удаление письма). Удалив письмо — пользователь и никто другой его больше не увидит. Однако двойной декремент прийти в теории может, вот именно этот риск и страхуется. Это если очень вкратце, на самом деле индексы писем — очень большая и важная подсистема почты, о ней я надеюсь сможем рассказать отдельно и более детально, там много интересностей.
Пока письмо у пользователя в списке писем есть — все его части должны быть доступны, иначе не поймут=)
2) Во-первых, хеши соленые, так что его нельзя угадать. Во-вторых, перебирать — этож сколько вариантов? В третьих — снаружи вообще нет интерфейса, позволяющего взять файл по хешу. Туда ходит только библиотека доступа к storage, и только она внутри себя знает как работать с этим хешом.
Я конечно всячески приветствую просвещение масс, но вы должны знать: пользователя это все не волнует. У него свои проблемы, свои термины, о которых мы с вами не знаем и не хотим знать. А он просто хочет прочитать почту.
Другой пример: возможно, вы бы хотели воспользоваться другим сотовым оператором, не меняя номера телефона. В этом случае вас бы сильно волновало почему DEF-префикс не позволяет вам так вот просто это сделать?
1. Популярен ли такой code style среди сотрудников Reg.ru?
2. Готовы ли вы принять автора-победителя к себе на работу?
Вариант с прокси рассматривали, возможно она могла бы решить часть проблем, но конечно не все. Сделать первую версию на asio оказалось гораздо проще и быстрее, а сам переход решил многие вопросы. Поэтому нужда в прокси пока отпала и решили не усложнять админам жизнь.
Насчет производительности — в этом посте взят пример http server 3 и просто собран «как есть». Способ обработки сами асинхронных событий в нём мне нравится, но вот остальной код кажется не слишком оптимальным. В частности, методы parse/consume в request_parser разбирает пришедшие данные побайтово, а все компоненты запроса кладёт в std::string по буквам, через push_back. Плюс, не учтена особенность strand, о которой говориться в этой статье. В подобных тестах нужно быть более осторожным=) Но конечно, спору нет: зачастую C++ библиотека будет работать медленнее plain-C. Я сторонник мнения, что лучше написать такие вещи быстрее, а сэкономленное время потратить на оптимизации самих алгоритмов, которые обычно «сьедают» больше ресурсов.