Я хотел бы зарезервировать порт TCP, который будет позднее связан с какой-либо службой, чтобы Windows случайно не использовала этот номер при назначении случайных номеров портов.Я знаю, что это возможно с помощью реестра и перезагрузки, но я бы хотел избежать такого сложного решения.
Как процесс может зарезервировать порт, не привязывая его / не прослушивая его, а затем безопасно (т. е. чтобы избежать условий гонки) передать его другому процессу по запросу?
Номер порта не нужно определять заранее.Первый процесс может получить случайный номер порта и передать его запрашивающему процессу.
РЕДАКТИРОВАТЬ: Мне приходит в голову, что мой вопрос несколько плохо сформулирован.Что я действительно хочу, так это отделить распределение номера динамического порта от операции привязки к порту-ноль.Это означает не только предотвращение случайного случайного распределения этого номера порта, но также предотвращение привязки любого другого процесса к тому же адресу / порту в промежуточный период.Или, говоря иначе, я хочу, чтобы один процесс запустил операцию bind-to-port-zero - сразу узнал номер порта, который будет использоваться - и позволил назначенному второму процессу завершить операцию bind когда-нибудь в будущем.
В настоящий момент самый близкий обходной путь, о котором я могу подумать, - это чтобы первый процесс немедленно связался с address / 0 и оставался связанным до тех пор, пока второй процесс не запросит его, после чего он отсоединится и сообщит другому процессуномер порта, который он получил, который затем явно привязывается к адресу / порту.У этого есть две проблемы: 1) я бы предпочел не связываться вообще, пока не наступит второй процесс;2) существует небольшой интервал времени, в течение которого третья сторона может случайно (или намеренно) узурпировать порт.
Справочная информация
Вам может быть любопытно, почему я хочу сделать что-то странное.Я играл с ZeroMQ, и одним из основных ограничений является отсутствие транспорта ipc:// в Windows.Меня поразило, что процесс сопоставления портов (похожий на сопоставление конечных точек RPC или epmd Эрланга) был бы просто билетом для реализации обходного пути с использованием транспорта tcp:// с динамическим распределением портов.Тем не менее, клиентам и серверам ZeroMQ разрешается подключаться не по порядку (т. Е. Клиент не ошибается при подключении до привязки сервера), поэтому я пытаюсь выяснить, как подключающийся клиент может обнаружить - с оченьвысокая степень уверенности - порт, который будет использоваться для связи до того, как сервер фактически подключится к этому порту.