Я разрабатываю серверное приложение в Linux, и у меня возник вопрос о поведении привязки сокетов при использовании INADDR_ANY и определенных IP-адресов. Моя настройка включает два сокета:
Один сокет привязан к порту 80 с помощью INADDR_ANY, что означает, что он прослушивает все доступные IP-адреса.
Другой сокет, привязанный к порту 80 на определенном IP-адресе, 66.117.236.114.
Мой вопрос:
Если клиент пытается подключиться к 66.117.236.114 через порт 80, существует ли вероятность того, что соединение может быть обработано сокет, привязанный к INADDR_ANY вместо явно привязанного к 66.117.236.114?
Я также использую опция сокета SO_REUSEADDR для обоих сокетов. Может ли это повлиять на маршрутизацию соединений или это связано исключительно с тем, что оба сокета могут без ошибок привязываться к одному и тому же порту?
Вот соответствующий фрагмент того, как я привязываю сокеты:
Сокет, привязанный к INADDR_ANY, прослушивает все доступные IP-адреса, в то время как другой сокет прослушивает только 66.117.236.114.
Опция SO_REUSEADDR позволяет обоим сокетам привязываться к одному и тому же порту без ошибок, но насколько насколько я понимаю, он не контролирует, какой сокет обрабатывает входящие соединения.
Мои ключевые вопросы:
[*]Есть ли сценарий, при котором соединение с адресом 66.117.236.114:80 может обрабатываться сокетом INADDR_ANY?
[*]Какую роль здесь играет SO_REUSEADDR? Влияет ли это на то, какой сокет обрабатывает входящие соединения, или это актуально только во время процесса привязки?
Желаемое поведение:
Я хочу, чтобы любые соединения, нацеленные на 66.117.236.114:80, всегда обрабатывались вторым сокетом (тот, который явно привязан к этому адресу), а соединения с другими IP-адресами (например, 127.0.0.1:80) обрабатываются сокетом INADDR_ANY.
Любые разъяснения или Будем очень признательны за подтверждение того, как Linux справляется с этим!
Я разрабатываю серверное приложение в Linux, и у меня возник вопрос о поведении привязки сокетов при использовании INADDR_ANY и определенных IP-адресов. Моя настройка включает два сокета: [list] [*]Один сокет привязан к порту 80 с помощью INADDR_ANY, что означает, что он прослушивает все доступные IP-адреса. [*]Другой сокет, привязанный к порту 80 на определенном IP-адресе, 66.117.236.114. [/list] Мой вопрос: [list] [*]Если клиент пытается подключиться к 66.117.236.114 через порт 80, существует ли вероятность того, что соединение может быть обработано сокет, привязанный к INADDR_ANY вместо явно привязанного к 66.117.236.114?
[*]Я также использую опция сокета SO_REUSEADDR для обоих сокетов. Может ли это повлиять на маршрутизацию соединений или это связано исключительно с тем, что оба сокета могут без ошибок привязываться к одному и тому же порту?
[/list] Вот соответствующий фрагмент того, как я привязываю сокеты: [code]int sock1 = socket(AF_INET, SOCK_STREAM, 0); int sock2 = socket(AF_INET, SOCK_STREAM, 0);
// Socket 2: Bind to specific IP address struct sockaddr_in addr2; addr2.sin_family = AF_INET; addr2.sin_addr.s_addr = inet_addr("66.117.236.114"); addr2.sin_port = htons(80); bind(sock2, (struct sockaddr*)&addr2, sizeof(addr2)); [/code] Что я уже узнал: [list] [*]Сокет, привязанный к INADDR_ANY, прослушивает все доступные IP-адреса, в то время как другой сокет прослушивает только 66.117.236.114. [*]Опция SO_REUSEADDR позволяет обоим сокетам привязываться к одному и тому же порту без ошибок, но насколько насколько я понимаю, он не контролирует, какой сокет обрабатывает входящие соединения. [/list] Мои ключевые вопросы: [*][b]Есть ли сценарий, при котором соединение с адресом 66.117.236.114:80 может обрабатываться сокетом INADDR_ANY?[/b] [*][b]Какую роль здесь играет SO_REUSEADDR?[/b] Влияет ли это на то, какой сокет обрабатывает входящие соединения, или это актуально только во время процесса привязки?
Желаемое поведение: Я хочу, чтобы любые соединения, нацеленные на 66.117.236.114:80, всегда обрабатывались вторым сокетом (тот, который явно привязан к этому адресу), а соединения с другими IP-адресами (например, 127.0.0.1:80) обрабатываются сокетом INADDR_ANY. Любые разъяснения или Будем очень признательны за подтверждение того, как Linux справляется с этим!