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