Windows два приложения на одном порту

Объединение двух программ одним портом Администрирование Windows Решение и ответ на вопрос 2487309

А что ты хочешь искать, не понял ?
Я же всё тебе расписал.
Твои две программы для COM-портов живут в гостевом виртуальном виндусе, в котором
необходимые им последовательные порты связаны с именованными каналами, это настраивается в свойствах самой виртуальной машины.
Но сами именованные каналы надо же создать. Создаст их приложение, которое живёт на хозяйском виндусе
и которое надо запустить перед запуском виртуальной машины.
После запуска виртуальной машины в ней надо запустить эти твои две программы, которые пишут и читают из com-портов,
но, поскольку эти виртуальные com-порты завязаны на именованные каналы, весь поток будет проходить через вышеуказанное приложение.
Итак, функционал данного приложения следующий:
— создаёт два именованных канала ( с именами, которые настроены в виртуальной машине )
— читает из одного канала, сохраняет всё это в LOG и направляет в другой канал

ВСЁ.

Добавлено через 4 минуты
PS: Такого рода приложения, которые перехватают трафик между com-портами, есть уже готовые,
но за них хотят денег. Бесплатных не видел. Поищи, может найдёшь.

When you create a TCP connection, you ask to connect to a specific TCP address, which is a combination of an IP address (v4 or v6, depending on the protocol you’re using) and a port.

When a server listens for connections, it can inform the kernel that it would like to listen to a specific IP address and port, i.e., one TCP address, or on the same port on each of the host’s IP addresses (usually specified with IP address 0.0.0.0), which is effectively listening on a lot of different «TCP addresses» (e.g., 192.168.1.10:8000, 127.0.0.1:8000, etc.)

No, you can’t have two applications listening on the same «TCP address,» because when a message comes in, how would the kernel know to which application to give the message?

However, you in most operating systems you can set up several IP addresses on a single interface (e.g., if you have 192.168.1.10 on an interface, you could also set up 192.168.1.11, if nobody else on the network is using it), and in those cases you could have separate applications listening on port 8000 on each of those two IP addresses.

When you create a TCP connection, you ask to connect to a specific TCP address, which is a combination of an IP address (v4 or v6, depending on the protocol you’re using) and a port.

When a server listens for connections, it can inform the kernel that it would like to listen to a specific IP address and port, i.e., one TCP address, or on the same port on each of the host’s IP addresses (usually specified with IP address 0.0.0.0), which is effectively listening on a lot of different «TCP addresses» (e.g., 192.168.1.10:8000, 127.0.0.1:8000, etc.)

No, you can’t have two applications listening on the same «TCP address,» because when a message comes in, how would the kernel know to which application to give the message?

However, you in most operating systems you can set up several IP addresses on a single interface (e.g., if you have 192.168.1.10 on an interface, you could also set up 192.168.1.11, if nobody else on the network is using it), and in those cases you could have separate applications listening on port 8000 on each of those two IP addresses.

Могут ли два приложения прослушивать один и тот же порт?

могут ли два приложения на одной машине привязываться к одному порту и IP-адресу? Более того, приложение можно слушать запросы с определенного IP, а другой на другой удаленный IP?
Я знаю, что могу иметь одно приложение, которое запускает два потока (или вилки), чтобы иметь подобное поведение, но могут ли два приложения, которые не имеют ничего общего, делать то же самое?

16 ответов


для TCP, нет. Вы можете одновременно прослушивать только одно приложение на одном порту. Теперь, если у вас есть 2 сетевые карты, вы можете прослушивать одно приложение на первом IP и втором IP, используя тот же номер порта.

для UDP (мультикаст), несколько приложений могут подписаться на один и тот же порт.


Да (для TCP) вы можете иметь две программы прослушивания на одном сокете, если программы предназначены для этого. Когда сокет создается первой программой, убедитесь, что SO_REUSEADDR опция установлена на сокете перед вами bind(). Однако это может быть не то, чего вы хотите. Это означает, что входящее TCP-соединение будет направлено на один программ, а не обоих, поэтому он не дублирует соединение, он просто позволяет двум программам обслуживать входящий запрос. Для например, веб-серверы будут иметь несколько процессов, прослушивающих порт 80, и O / S отправляет новое соединение процессу, который готов принять новые соединения.

SO_REUSEADDR

другие розетки bind() к этому порту, если нет активного слушающего сокета, привязанного к порту уже. Это позволяет обойти сообщения об ошибках «адрес уже используется» при попытке перезапустить сервер после сбоя.


в принципе, нет.

Это не написано на камне; но так пишутся все API: приложение открывает порт, получает к нему дескриптор, и ОС уведомляет его (через этот дескриптор), когда клиентское соединение (или пакет в случае UDP) прибывает.

Если ОС разрешила двум приложениям открывать один и тот же порт, как она узнает, какой из них уведомить?

но… есть способы обойти это:

  1. Как Джед отметить, вы могли бы написать «мастер» процесс, который был бы единственным, который действительно слушает порт и уведомляет других, используя любую логику, которую он хочет разделить запросы клиента.
    • в Linux и BSD (по крайней мере) вы можете настроить правила «переназначения», которые перенаправляют пакеты с «видимого» порта на другие (где приложения прослушивают), в соответствии с любыми сетевыми критериями (возможно, сеть происхождения или некоторые простые формы балансировки нагрузки).

Да.

  1. несколько прослушивающих TCP-сокетов, привязанных к одному порту, могут сосуществовать при условии, что все они привязаны к различным локальным IP-адресам. Клиенты могут подключаться к любому из них. Это исключает 0.0.0.0 (INADDR_ANY).

  2. несколько принят гнезда могут сосуществовать, все принятые от такого же слушая гнезда, все показывая такой же местный номер порта как слушать разъем.

  3. несколько сокетов UDP, связанных с одним и тем же портом, могут сосуществовать при условии, что либо то же условие, что и в (1), либо все они имели SO_REUSEADDR опция, установленная перед привязкой.

  4. TCP-порты и UDP-порты занимают разные пространства имен, поэтому использование порта для TCP не исключает его использования для UDP и наоборот.

Ссылка: Стивенс И Райт,TCP / IP иллюстрированный, Том II.


нет. Только одно приложение может привязываться к порту одновременно, и поведение, если привязка принудительная, неопределенно.

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

вы можете выполнить это, написав процесс «master», который принимает и обрабатывает все соединения, а затем передает их вашим двум приложениям, которым нужно слушать тот же порт. Это подход, который веб-серверы и такие принимают, так как многие процессы должны слушать 80.

помимо этого, мы переходим к деталям — вы отметили как TCP, так и UDP, что это? Кроме того, какая платформа?


Да, Конечно. Насколько я помню, начиная с версии ядра 3.9 (не уверен в версии), поддержка . SO_RESUEPORT позволяет привязку к тому же порту и адресу, если первый сервер устанавливает этот параметр перед привязкой сокета.

это работает для обоих TCP и UDP. Более подробную информацию см. по ссылке:SO_REUSEPORT

Примечание: принято отвечать больше не соответствует моему мнению.


вы можете иметь одно приложение на один порт для одного сетевого интерфейса. Поэтому вы могли бы:

  1. httpd прослушивание на удаленно доступном интерфейсе, например 192.168.1.1:80
  2. еще один демон прослушивает 127.0.0.1:80

пример использования может быть использование httpd Как балансировщик нагрузки или прокси.


другой способ-использовать прослушивание программы в одном порту, который анализирует вид трафика (ssh, https и т. д.), который он перенаправляет внутренне на другой порт, на котором прослушивается «реальная» служба.

например, для Linux, sslh: https://github.com/yrutschle/sslh


Если хотя бы один из удаленных IPs уже известен, статичен и предназначен для разговора только с одним из ваших приложений, вы можете использовать правило iptables (таблица nat, цепная предварительная маршрутизация) для перенаправления трафика с этого адреса на «общий» локальный порт на любой другой порт, где соответствующее приложение действительно прослушивает.


да и нет. Только одно приложение может активно прослушивать порт. Но это приложение может завещать свою связь с другим процессом. Таким образом, вы можете иметь несколько процессов, работающих на одном порту.



когда вы создаете TCP-соединение, вы просите подключиться к определенному TCP-адресу, который представляет собой комбинацию IP-адреса (v4 или v6, в зависимости от используемого протокола) и порта.

когда сервер прослушивает соединения, он может сообщить ядру, что он хотел бы прослушивать определенный IP-адрес и порт, т. е. один IP-адрес, или на всех IP-адресах хостов, каждый на определенном порту, который эффективно прослушивает много разных «TCP-адресов» (например,, 192.168.1.10:8000, 127.0.0.1:8000 и др.)

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

однако в большинстве операционных систем вы можете настроить несколько IP-адресов на одном интерфейсе (например, если у вас есть 192.168.1.10 на интерфейсе, вы также можете настроить 192.168.1.11, если никто другой в сети не использует его), и в этих случаях вы может иметь отдельные приложения, прослушивающие порт 8000 на каждом из этих двух IP-адресов.


Если под приложениями вы подразумеваете несколько процессов, то да, но обычно нет.
Например, Apache server запускает несколько процессов на одном порту (обычно 80).Это делается путем назначения одного из процессов для фактической привязки к порту, а затем использовать этот процесс для передачи различных процессов, которые принимают соединения.


можно сделать два приложения, прослушивать один и тот же порт на одном сетевом интерфейсе.

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

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


я попробовал следующее, С socat:

socat TCP-L:8080,fork,reuseaddr -

и хотя я не подключился к сокету, я не могу прослушивать дважды один и тот же порт, несмотря на .

Я получаю это сообщение (которое я и предполагал ранее):

2016/02/23 09:56:49 socat[2667] E bind(5, {AF=2 0.0.0.0:8080}, 16): Address already in use

короткий ответ:

идем на ответ здесь. У вас может быть два приложения, прослушивающие один и тот же IP-адрес и номер порта, так что один из портов является UDP-портом, а другой-TCP-портом.

пояснение:

концепция порта уместна на транспортном уровне стека TCP/IP, таким образом, пока вы используете различные протоколы транспортного уровня стека, вы можете иметь несколько процессы прослушивания на одном и том же <ip-address>:<port> комбинации.

одно сомнение, что люди есть, если два приложения работают на одном и том же <ip-address>:<port> комбинация, как клиент, работающий на удаленной машине, различает их? Если вы посмотрите на заголовок пакета IP-уровня (https://en.wikipedia.org/wiki/IPv4#Header), вы увидите, что биты 72 до 79 используются для определения протокола, вот как можно сделать различие.

однако, если вы хотите иметь два приложения на одном TCP <ip-address>:<port> комбинация, тогда ответ нет (интересным упражнением будет запуск двух виртуальных машин, дайте им один и тот же IP — адрес, но разные MAC — адреса, и посмотрите, что произойдет-вы заметите, что в некоторых случаях VM1 получит пакеты, а в других случаях VM2 получит пакеты-в зависимости от обновления кэша ARP).

Я чувствую, что, заставляя два приложения работать на одном и том же <op-address>:<port> вы хотите достичь какой-то балансировки нагрузки. Для этого вы можете запускать приложения на различные порты, и написать правила таблицы IP для разделения трафика между ними.

Также см. ответ @user6169806.


When you create a TCP connection, you ask to connect to a specific TCP address, which is a combination of an IP address (v4 or v6, depending on the protocol you’re using) and a port.

When a server listens for connections, it can inform the kernel that it would like to listen to a specific IP address and port, i.e., one TCP address, or on the same port on each of the host’s IP addresses (usually specified with IP address 0.0.0.0), which is effectively listening on a lot of different «TCP addresses» (e.g., 192.168.1.10:8000, 127.0.0.1:8000, etc.)

No, you can’t have two applications listening on the same «TCP address,» because when a message comes in, how would the kernel know to which application to give the message?

However, you in most operating systems you can set up several IP addresses on a single interface (e.g., if you have 192.168.1.10 on an interface, you could also set up 192.168.1.11, if nobody else on the network is using it), and in those cases you could have separate applications listening on port 8000 on each of those two IP addresses.

When you create a TCP connection, you ask to connect to a specific TCP address, which is a combination of an IP address (v4 or v6, depending on the protocol you’re using) and a port.

When a server listens for connections, it can inform the kernel that it would like to listen to a specific IP address and port, i.e., one TCP address, or on the same port on each of the host’s IP addresses (usually specified with IP address 0.0.0.0), which is effectively listening on a lot of different «TCP addresses» (e.g., 192.168.1.10:8000, 127.0.0.1:8000, etc.)

No, you can’t have two applications listening on the same «TCP address,» because when a message comes in, how would the kernel know to which application to give the message?

However, you in most operating systems you can set up several IP addresses on a single interface (e.g., if you have 192.168.1.10 on an interface, you could also set up 192.168.1.11, if nobody else on the network is using it), and in those cases you could have separate applications listening on port 8000 on each of those two IP addresses.

 
MaximP
 
(2005-04-18 12:13)
[0]

Уважаемые мастера подскажите как разрулить ситуацию.
Дело в следующем есть несколько программ-серверов на одной машине и используют один порт, дак вот проблемма в том что как раз один порт и не используют по причине того что машина ругается что возможно использование протокола/сетевого адрес/порта только одним приложением. Использую ServerSocket1. Подскажите в каком направлении рыть.


 
Anatoly Podgoretsky ©
 
(2005-04-18 12:20)
[1]

В сторону коммутатора.


 
dmitry501 ©
 
(2005-04-18 12:22)
[2]

Менять используемые порты.


 
Alex Konshin ©
 
(2005-04-18 12:32)
[3]

Если говорит, что используешь, значит, используешь.
Как эти программы работают? Кто их запускает? Когда и как они завершаются? Возможен ли запуск нескольких копий?


 
MaximP
 
(2005-04-18 12:44)
[4]


> dmitry501 ©   (18.04.05 12:22) [2]

Менять порты не выход.
Опишу ситуацию чуть подробней, может посоветуете другой выход.
Есть сеть локальная, пользователи запускают программы расположеные на сетевом диске. мне нужно знать какие программы и кем запущены.
Что сделал: разбил задачу на два этапа
1)(Уже сделал) определил имена машин, пользователей, ip- адреса всех кто в настоящее время подключен к сети. Сделал.
2)(сделано в тестовом варианте в котором и наткнулся на проблему)в каждую из програм запускаемых пользователями разместил компонент ServerSocket в задачу которого и входит отвечать клиенту ClientSocket расположенный в программе которая и отражает все машины с приложениями в которые интегрирован модуль сервера. И всё бы хорошо если бы пользователи не запускали по несколько программ, а также по несколько экземпляров одной программы, а им это нужно.
Конечно это извращение плодить столько серверов, но как поступить?


 
atruhin ©
 
(2005-04-18 14:14)
[5]

Ну дак поменяй ClientSocket и ServerSocket местами


 
MaximP
 
(2005-04-18 14:35)
[6]


> atruhin ©   (18.04.05 14:14) [5]

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


 
atruhin ©
 
(2005-04-19 07:36)
[7]

1. Сервер запускается посылает широковещательное сообщение о том что он запущен, остальные программы, приняв рассылку, коннектятся к нему (так многие игрушки работают).
2. Любая из версий программы обеспечивает транспортный канал для других. Вторая копия при запуске проверяет, что канал создан, и пересылает свои пакеты используя любой тип межпроцессорного взаимодействия.
3. Ну и пусть стучаться к серверу, по таймеру скажем раз в 10 сек., сеть этим не нагрузишь.


 
MaximP
 
(2005-04-19 19:17)
[8]


> atruhin ©   (19.04.05 07:36) [7]

Заинтересовал 1 выриант, вот только как послать широковещательное сообщение?


 
atruhin ©
 
(2005-04-20 09:11)
[9]

UDP


 
MaximP
 
(2005-04-20 13:08)
[10]


> atruhin ©   (20.04.05 09:11) [9]

Понял, буду разбираться!


Понравилась статья? Поделить с друзьями:
  • Windows грузится только со стороннего загрузчика
  • Windows грузится не с того диска
  • Windows графикалы? интерфейсіні? иерархиялы? ж?йесіндегі жо?ар?ы сатысы не
  • Windows горячие клавиши открыть в новом окне папку
  • Windows горячая клавиша переименовать файл windows