Windows: как нескольким процессам принимать данные с одного UDP порта?

Question

[tamamo]

Как нескольким процессам в Windows одновременно принимать данные из одного UDP порта ? Подразумевается, что если на открытый UDP порт приходит датаграмма - то её получают сразу все процессы, у которых был bind данного порта.

На сколько понятно из MSDN SO_REUSEADDR не используется с UDP сокетами и означает немного другое.

Как реализовать такое поведение стандартным WinAPI без использования драйверов, LSP (layered service provider), и без необходимости поднимать процесс-ретранслятор - который получает пакеты с конкретного UDP порта и передаёт их остальным процессам ? без всего вот этого вот ? просто программка использующая windows api ?

Comments

[Владимир Пилипчук]

Немного бы контекста. Какова архитектура приложения, каков его сетевой стэк? От этого многое зависит.
Пока только multicast на ум приходит.

[hint000]

А чем не нравится процесс-ретранслятор? Это как раз самое очевидное и простое решение без необходимости ломать голову.

[pfg21]

Либо писать свой ретранслятор с эффективной логикой.
либо отдавать этот ретранслятор системе, и пытаться правильно его настроить.
Зачем ??

[tamamo]

Владимир Пилипчук, обычный си + WinAPI, т.е. socket(), bind(), recvfrom(), и вот это вот все.
hint000, потому что это во первых медленно, очень медленно, во вторых - это костыль - потому что должен быть один процесс который главнее всех остальных, и в случае его падения будет короткий промежуток времени в который пакеты будут теряться. ну до тех пор пока кто то не решит взять на себя роль нового ретранслятора ...

Основная задача - чтобы процессы вычленяли из входящего траффика нужную им информацию и работали синхронно. Если кто-то падает - траффик не теряется - остальные обрабатывают то что пришло параллельно запуская упавший процесс, который может грузиться в условиях нагрузки несколько минут.

[tamamo]

pfg21, А отдавать ретранслятор системе - что именно это значит ?

[tamamo]

hint000, Не хотелось бы уходить далеко от изначальной темы вопроса ...... Простейшая причина падения процесса - сторонние DLL для которых нет исходников. Даже если все вызовы обернуть в исключения - нет никакой гарантии что процесс не уронит поток запускаемый внутри DLL или что DLL не испортит память основного процесса. Происходит это не редко. Простейшая причина почему программа долго загружается - сложные распределённые структуры данных, "размазанные" по 20+ инстансам программы, часть из которых (обычно 4 штуки) сидит на одном сервере, остальные - на других физически отдельных серверах (это обусловлено 128 гб RAM на сервер). После запуска программа сначала получает из разных источников (в том числе и от других инстансов) кучу данных, формируя у себя в памяти структуры объёмом около 20 гигабайт. Затем эти структуры подготавливаются к "запуску программы" - то есть приводятся в состояние, начиная с которого мы можем отвечать на входящие запросы и что то отправлять обратно - на это тоже нужно время. Итоговое время запуска может составлять до 15 минут. Да, легаси тут безусловно есть - можно и серверы по мощнее взять и сеть по лучше. Но тут вот какая штука. Сейчас из 8 серверов если четыре уничтожить - ничего не измениться. Поставил новые серверы - запустил приложение - через пять часов всё отреплицировалось. Причём всё это в реальном времени без падения производительности системы. Серверы можно подключать к разным каналам питания, и т.д. и т.п. - в целом тут например очень высокая отказоустойчивость. Можно вообще десктопные машины использовать - просто квантование данных будет другое.

И хоть конечно здесь везде море проблемы - начиная от сторонних модулей - и заканчивая отсутствием нормальных бесперебойников - но работать приходится на том оборудовании которое есть и с тем легаси которое есть в наличии.

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

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

[Владимир Пилипчук]

tamamo, ну так используйте очередь. RMQ и Компания, например. Решите массу других возможных проблем одним махом. Ну либо поверх UDP реализовать свой собственный протокол или использовать уже существующий (типа RTMP).

Answer 1

[mayton2019]

Вот я так делал. Это работает под Linux. Только процесс который прослушивает UDP сокет
должен подняться первым. А потом уже можно поднимать торрент клиент к примеру
и они будуд разделять этот сокет. В обратном порядке - не сработает.

sockfd = socket(AF_INET, SOCK_DGRAM, 0);
    if (sockfd < 0) {
        perror("Error creating socket");
        exit(1);
    }

    int reuse = 1;

    if (setsockopt(sockfd, SOL_SOCKET, SO_REUSEADDR, &reuse, sizeof(reuse)) < 0) {
        perror("Error setting socket option");
        exit(1);
    }

    server_addr.sin_family      = AF_INET;
    server_addr.sin_addr.s_addr = htonl(INADDR_ANY);
    server_addr.sin_port        = htons(atoi(sin_port));

    if (bind(sockfd, (struct sockaddr*)&server_addr, sizeof(server_addr)) < 0) {
        perror("Error binding socket");
        exit(1);
    }