Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[18.222.153.44] |
|
Страницы: (2) [1] 2 все ( Перейти к последнему сообщению ) |
Сообщ.
#1
,
|
|
|
Есть у меня клиент-серверное приложение.
Запускаю сервер и клиента на одной машине. И дальше варианты: 1) На клиенте указываю сервер как 127.0.0.1 и говорю, что клиент должен коннектиться от имени 127.0.0.2 -> все работает. 2) На клиенте указываю сервер как 127.0.0.1 и говорю, что клиент должен коннектиться от имени 192.168.10.100 -> "No connection could be made because the target machine actively refused it." 3) На клиенте указываю сервер как 192.168.10.100 и говорю, что клиент должен коннектиться от имени 127.0.0.2 -> "No connection could be made because the target machine actively refused it." 4) На клиенте указываю сервер как 192.168.10.100 и говорю, что клиент должен коннектиться от имени 192.168.10.100 -> все работает. Это какая-то особенность TCP? Где про этот эффект можно почитать? |
Сообщ.
#2
,
|
|
|
Цитата Fester @ "No connection could be made because the target machine actively refused it." Это шуточки фаервола. ОС у вас какая? |
Сообщ.
#3
,
|
|
|
Нет тут никакого "эффекта". Основы маршрутизации - узлы из разных подсетей не могут общаться напрямую.
|
Сообщ.
#4
,
|
|
|
OS - Win7, также ещё на Win10 или Win Server 2012.
Akina, а как сделать, чтобы все работало? |
Сообщ.
#5
,
|
|
|
У тебя два рабочих набора настроек - какого тебе ещё надо-то?
Кстати, раз это всё происходит на одном инстансе ОС, то первый вариант предпочтителен. |
Сообщ.
#6
,
|
|
|
Цитата Fester @ No connection could be made because the target machine actively refused it." Это ошибка 10061. И как видно по ошибке, сервер таки получает SYN от клиента, но отвечает RST. Не хочет ставить запрос в очередь. Т.е. сервер ВИДИТ клиента, SYN сегмент до него доходит. Вариантов тут много, вот тут http://rsdn.org/forum/network/1365288.flat они обсуждаются. Один из вариантов - на сервере мала очередь входящих запросов. Вот еще один вариант http://www.php.su/forum/topic.php?forum=1&topic=8042 Еще один вариант - это тот о котором говорит Акина. Стек TCP/IP лакальной машины ведь ОДИН и тот же, а его заставляют работать в разных подсетях...хотя что до меня так это проблематично - так как сервер все таки видит клиента, если шлет ему RST. В общем вариантов много. Еще одна фишка именно с отладкой на одной и той же машине клиента и сервера. Во все функции коннекта, приема передачи и тд надо вставлять SLEEP()на миллисекунд 50 примерно чтобы не заставлять стек корячиться одновременно с двумя сетевыми приложениями. Т.е. простое моделирование обычных задержек в реальной сети. |
Сообщ.
#7
,
|
|
|
Fester
Просто в свойствах брандмауэра пропишите нужные адреса. Дело в том что из локальной сети в частные закрыт видимо в целях безопасности. Нужно явно прописать 127.0.0.1/24 Учтите что это надо сделать для обоих профилей "частный" и "общий" (или "все") Пуска -> панель управления ->администрирование -> Монитор брандмауэра Защитника Windows в режиме повышенной безопасности Прикреплённый файл_____________________1.png (247,79 Кбайт, скачиваний: 451) |
Сообщ.
#8
,
|
|
|
Прошу прощение, я скопировал не то сообщение
1) На клиенте указываю сервер как 127.0.0.1 и говорю, что клиент должен коннектиться от имени 127.0.0.2 -> все работает. 2) На клиенте указываю сервер как 127.0.0.1 и говорю, что клиент должен коннектиться от имени 192.168.10.100 -> "The requested address is not valid in its context 127.0.0.1:4001" (код ошибки 10049) 3) На клиенте указываю сервер как 192.168.10.100 и говорю, что клиент должен коннектиться от имени 127.0.0.2 -> "A socket operation was attempted to an unreachable network. 192.168.10.100:4001" (код ошибки 10051) 4) На клиенте указываю сервер как 192.168.10.100 и говорю, что клиент должен коннектиться от имени 192.168.10.100 -> все работает. |
Сообщ.
#9
,
|
|
|
Я только не понимаю, почему ты не используешь самый очевидный в режиме одного инстанса ОС вариант - и клиент, и сервер с адресом 127.0.0.1... зачем нужен этот выверт с 127.0.0.2?
|
Сообщ.
#10
,
|
|
|
Там нет разницы 127.0.0.1 или 127.0.0.2
Ну а 127.0.0.2 использую, просто потому что мне надо симулировать много клиентов (клиентов мы различаем по IP) и если сервер крутится на 127.0.0.1, то симулировать 10 клиентов я смогу просто отправляя сообщения с адресов 127.0.0.1, 127.0.0.2, ..., 127.0.0.10 В принципе я могу добавить логику и если сервер указан как 127.*.*.*, то не показывать все остальные IP (кроме 127.*.*.*), а если указан любой другой IP, то я буду брать IPшники с адаптора. Собственно говоря подозреваю, что именно так и надо будет сделать... но шеф хочет объяснения, почему это так. |
Сообщ.
#11
,
|
|
|
Цитата Fester @ шеф хочет объяснения, почему это так Ну потыкай его носом в основы маршрутизации, что ли... узел может напрямую общаться только с узлом из той же подсети (и то - с исключениями), для остальных необходимо наличие маршрутизирующего шлюза. А адреса 127.0.0.1 и 192.168.10.100 могут быть в одной подсети, только если это сеть 0.0.0.0/0, чего операционная система тупо не примет... |
Сообщ.
#12
,
|
|
|
Цитата Fester @ 127.0.0.1 Это отдельный виртуальный интерфейс для проверки сетевого стека, он не маршрутизируется с реальными интерфейсами, смотри таблицу маршрутизации. 127.0.0.1 это адрес и интерфейс. А так-же любой адрес подсети 127.x.x.x принадлежит интерфейсу 127.0.0.1. IPv4 таблица маршрута =========================================================================== Активные маршруты: Сетевой адрес Маска сети Адрес шлюза Интерфейс Метрика 0.0.0.0 0.0.0.0 10.10.1.200 10.10.1.46 20 10.10.1.0 255.255.255.0 On-link 10.10.1.46 276 10.10.1.46 255.255.255.255 On-link 10.10.1.46 276 10.10.1.255 255.255.255.255 On-link 10.10.1.46 276 127.0.0.0 255.0.0.0 On-link 127.0.0.1 306 127.0.0.1 255.255.255.255 On-link 127.0.0.1 306 127.255.255.255 255.255.255.255 On-link 127.0.0.1 306 192.168.56.0 255.255.255.0 On-link 192.168.56.1 266 192.168.56.1 255.255.255.255 On-link 192.168.56.1 266 192.168.56.255 255.255.255.255 On-link 192.168.56.1 266 224.0.0.0 240.0.0.0 On-link 127.0.0.1 306 224.0.0.0 240.0.0.0 On-link 10.10.1.46 276 224.0.0.0 240.0.0.0 On-link 192.168.56.1 266 255.255.255.255 255.255.255.255 On-link 127.0.0.1 306 255.255.255.255 255.255.255.255 On-link 10.10.1.46 276 255.255.255.255 255.255.255.255 On-link 192.168.56.1 266 =========================================================================== |
Сообщ.
#13
,
|
|
|
Цитата ^D^ima @ Это отдельный виртуальный интерфейс для проверки сетевого стека Если с первой половиной согласен, то вот вторая - насчёт "для проверки",- вызывает определённые сомнения. И ещё я дополнительно бы указал, что любой сетевой узел имеет такой внутренний интерфейс. Т.е. любое обращение к нему - это обращение к себе, а не наружу... |
Сообщ.
#14
,
|
|
|
Цитата ^D^ima @ смотри таблицу маршрутизации Мне это ни о чем не говорит Цитата ^D^ima @ 127.0.0.1 это адрес и интерфейс. В твоем списке одинаковая картина для 10.10.1.46, 127.0.0.1 и 192.168.56.1 Значит ли это, что с 10.10.1.46 можно обращаться к 127.0.0.1 или к 192.168.56.1 и обратно? Или для того, чтобы можно было установить соединение должен быть один и тот же интерфейс? Посмотрел у себя - тоже самое - 10.2.5.1 - это и адрес и интерфейс, также как и 127.0.0.1. Связи нет. |
Сообщ.
#15
,
|
|
|
^D^ima
В принципе можно было бы с вами согласиться. Но ведь SYN от клиента приходит к серверу и наоборот от сервера приходит RST. И занимается этой рассылкой ОДИН и ТОТ же стек. Поэтому скорее всего я бы посчитал такое поведение особенностью стека TCP/IP - стек понимает бессмысленность обмена между реальным и виртуальным интерфейсами. Потому и RST. Имхо. |