Я хотел бы зарезервировать TCP-порт, который позже будет связан службой, так что Windows не будет непреднамеренно использовать один и тот же номер при назначении случайных номеров портов. Я знаю, что это возможно через реестр и перезагрузка, но я бы хотел избежать такого жесткого решения.
Как процесс может зарезервировать порт без фактического привязки/прослушивания, а затем безопасно (т.е. избегая условий гонки) передать его другому процессу по запросу?
Номер порта не обязательно должен быть определен заранее. Это нормально, чтобы первый процесс приобрел случайный номер порта и передал его процессу запроса.
EDIT: Мне кажется, что мой вопрос несколько плохо сформулирован. Я действительно хочу отделить выделение номера динамического порта от операции привязки к порту-ноль. Это означает, что вы не просто избегаете случайного случайного распределения этого номера порта, но также предотвращаете привязку любого другого процесса к одному и тому же адресу/порту в промежуточный период. Или, говоря другим способом, я хочу, чтобы один процесс запустил операцию привязки к порту-ноль - сразу же узнав номер порта, который будет использоваться, и пусть назначенный второй процесс завершит операцию привязки в будущем.
В настоящий момент самое близкое взаимодействие, о котором я могу думать, заключается в том, что первый процесс сразу связывается с адресом /0 и остается связанным до тех пор, пока второй процесс не запросит его, и в этот момент он отсоединяет и сообщает другому процессу номер порта, который он приобрел, который затем привязывается к адресу/порту явно. У этого есть две проблемы: 1) я бы предпочел не связываться вообще до тех пор, пока не будет второй процесс; 2) существует небольшой промежуток времени, в течение которого третья сторона может случайно (или намеренно) узурпировать порт.
Фон
Вам может быть интересно узнать, почему я хочу сделать что-то такое странное. Я работал с ZeroMQ, и одним из основных ограничений является отсутствие транспорта ipc:// в Windows. Мне показалось, что процесс сопоставления портов (аналогичный RPC endpoint mapper или Erlang epmd) будет всего лишь билетом для реализации обхода с использованием транспорта tcp:// с динамическими распределениями портов. Тем не менее, клиентам и серверам ZeroMQ разрешено подключаться не по порядку (т.е. Это не ошибка для подключения клиента до привязки сервера), поэтому я пытаюсь выяснить, как можно обнаружить подключающийся клиент - с очень высокая степень достоверности - порт, который будет использоваться для связи, до того, как сервер действительно свяжется с этим портом.
