Задать вопрос
  • Почему в Linux приложение может удалить само себя, а в Windows нет?

    saboteur_kiev
    @saboteur_kiev Куратор тега Linux
    software engineer
    Когда процесс открывает файл, он открывает дескриптор на определенную структуру данных. Эта структура содержит аттрибуты файла, права доступа, информацию о том, где хранятся данные файла и так далее.

    В Win и *nix эта информация хранится в разных местах, и соответственно лок происходит по-разному.

    В POSIX системах (unix, linux, etc.) информация о файле хранится iNode, а имя файла уже ссылается на iNode.

    В Windows и DOS изначально информация о файле хранилась в структуре которая называется Directory Entry. В NTFS это немного изменилось, но подход они не меняли либо для обратной совместимости, либо не видели в этом нужды.

    Собственно отсюда исторически и выросло, что в *nix при открытии файла дескриптор указывает на iNode, а само имя файла можно при этом свободно удалять, или делать несколько имен ссылающихся на одну iNode (hard link), которые можно произвольно менять, пока "файл открыт".

    В Windows лочится непосредственно Directory Entry (или ее аналог в NTFS), следовательно его модифицировать в этот момент нельзя.

    У обоих подходов есть свои плюсы и минусы и история. Пока нет предпосылок к тому, что на Windows захотят изменить подход.
    Ответ написан
    Комментировать
  • Как работают современные мессенджеры?

    xmoonlight
    @xmoonlight
    https://sitecoder.blogspot.com
    Конкретно интересует часть с хранением и отдачей сообщений, так как не могу понять, как сервер за столь короткое время умеет прошерстить базу данных, найти сообщения конкретного пользователя и отдать их.
    "Древовидный" спуск. Обычно "корень" привязан к ID пользователя чата.

    Еще интересует сторона шифрования, особенно в том случае, когда не используется e2e шифрование, то есть как следить за безопасностью/утечками, заранее спасибо за ответ.
    Никак. Утечки неминуемы, если не используется 3-х стороннее шифрование.
    Ответ написан
    Комментировать
  • Как работают современные мессенджеры?

    paran0id
    @paran0id
    Умный, но ленивый
    Что касается обработки сообщений, я бы использовал не sql-базу, а какую-нибудь шину типа apache kafka. И какой-нибудь KSQL для поиска и других операций с историей. Тогда получение и доставка сообщений будет происходить быстро.
    Ответ написан
    1 комментарий
  • Как работают современные мессенджеры?

    EvgenyMamonov
    @EvgenyMamonov
    Senior software developer, system architect
    как сервер за столь короткое время умеет прошерстить базу данных, найти сообщения конкретного пользователя и отдать их

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

    Что касается быстрой загрузки истории сообщений - то тут нужно сохранять сообщения таким образом, чтобы сообщения одного пользователя всегда были на одном и том же сервере (если используется шардинг). Тогда обычный SELECT из базы по user_id будет вполне себе быстро работать даже на огромной базе. Также таблицы можно еще партицировать, чтобы еще быстрее загружать последние сообщения в истории.

    Что касается безопасности, если не использовать e2e шифрование, как вариант, можно использовать обычные RSA ключи. Например на сервере генерируем два ключа, открытый отправляем кленту, он шифрует им сообщение и передает сообщение на сервер. Вы на сервере его расшифровываете при помощи закрытого ключа. Для отправки сообщения клиенту, можно сделать тоже самое. Клиент также генерирует два RSA ключа и открытый ключ отправляет серверу. Когда серверу нужно доставить сообщение клиенту, он шифрует сообщение открытым ключём, который ему высылал клиент и отправляет ему.

    Мне тоже интересно узнать другие варианты решения этой задачи, буду следить за этой темой :)

    Хорошее дополнение по хранению сообщения и организации поиска от Ильи
    Распределение нагрузки решается шардингом — получается много небольших БД вместо одной огромной. Скорее всего каждое сообщение разбивается по словам/частям слов и сохраняется в поисковый индекс типа слово—message_id и такой индекс строится для каждого пользователя и тоже шардируется. При поиске сначала получаем идентификаторы подходящих сообщений из поискового индекса, потом выгружаем сообщения из БД с сообщениями.

    Дополнение от Stalker_RED
    только не "сообщения одного пользователя всегда были на одном и том же сервере" а сообщения из одного чата/канала/группы (включая чаты, в котором всего два участника). То-же самое касается построения индекса.
    Ответ написан
    7 комментариев