Зарезервировать TCP-порт в Windows

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

Как процесс может зарезервировать порт без фактического связывания / прослушивания его, а затем безопасно (т. Е. Избегая race-conditions) передать его другому процессу по запросу?

Номер порта не нужно определять заранее. Это нормально, если первый процесс получит случайный номер порта и передаст его запрашивающему процессу.

РЕДАКТИРОВАТЬ: Мне приходит в голову, что мой вопрос несколько плохо сформулирован. Что мне действительно нужно, так это отделить выделение динамического номера порта от операции привязки к нулю порта. Это означает не только предотвращение случайного случайного выделения этого номера порта, но также предотвращение привязки любого другого процесса к тому же адресу / порту в промежуточный период. Или, говоря другими словами, я хочу, чтобы один процесс запустил операцию привязки к нулю порта - немедленно узнал номер порта, который будет использоваться - и позволил назначенному второму процессу завершить операцию привязки когда-нибудь в будущем.

На данный момент ближайший обходной путь, который я могу придумать, - это когда первый процесс немедленно привязывается к адресу / 0 и остается связанным до тех пор, пока второй процесс не запросит его, после чего он отключает привязку и сообщает другому процессу номер порта. он приобрел, который затем явно привязывается к адресу / порту. У этого есть две проблемы: 1) я бы предпочел вообще не связывать, пока не появится второй процесс; 2) есть небольшой интервал времени, в течение которого третье лицо может случайно (или намеренно) захватить порт.

Общие сведения

Вам может быть любопытно, почему я хочу сделать что-то настолько странное. Я играл с ZeroMQ, и одним из основных ограничений является отсутствие транспорта ipc: // в Windows. Меня поразило, что процесс сопоставления портов (сродни сопоставителю конечных точек RPC или epmd в Erlang) был бы всего лишь билетом для реализации обходного пути с использованием транспорта tcp: // с динамическим распределением портов. Однако клиентам и серверам ZeroMQ разрешено подключаться не по порядку (т. Е. Подключение клиента до привязки сервера не является ошибкой), поэтому я пытаюсь выяснить, как подключающийся клиент может обнаружить - с очень высокой степенью уверенности - порт, который будет использоваться для связи, до того, как сервер действительно привяжется к этому порту.