Допустим есть клиент на TCP сокетах, он подключается к какому-то серверу. У клиенского сокета есть локальный порт, например 52042. После того как этот клиент приконнектился, пробуем на этой же (клиентской) машине поднять какой-нибудь TCP сервер, забиндив его на тот же самый порт 52042. Он поднимается и корректно работает (работает на windows и на linux). Dопрос — какого фига ? Есть предположение что эфемерные порты можно юзать в качестве listening, но вот реального подтверждения не смог найти. Может быть, кто-то в курсе этой темы и может сказать точно ?
Здравствуйте, elw00d, Вы писали:
E>Допустим есть клиент на TCP сокетах, он подключается к какому-то серверу. У клиенского сокета есть локальный порт, например 52042. После того как этот клиент приконнектился, пробуем на этой же (клиентской) машине поднять какой-нибудь TCP сервер, забиндив его на тот же самый порт 52042. Он поднимается и корректно работает (работает на windows и на linux). Dопрос — какого фига ? Есть предположение что эфемерные порты можно юзать в качестве listening, но вот реального подтверждения не смог найти. Может быть, кто-то в курсе этой темы и может сказать точно ?
В можно код клиента посмотреть? Что-то сомнения у меня, что это работает в Windows...
Re[2]: Можно ли использовать занятый эфемерный порт в bind() ?
Здравствуйте, Nikolay_Ch, Вы писали:
N_C>Здравствуйте, elw00d, Вы писали:
E>>Допустим есть клиент на TCP сокетах, он подключается к какому-то серверу. У клиенского сокета есть локальный порт, например 52042. После того как этот клиент приконнектился, пробуем на этой же (клиентской) машине поднять какой-нибудь TCP сервер, забиндив его на тот же самый порт 52042. Он поднимается и корректно работает (работает на windows и на linux). Dопрос — какого фига ? Есть предположение что эфемерные порты можно юзать в качестве listening, но вот реального подтверждения не смог найти. Может быть, кто-то в курсе этой темы и может сказать точно ? N_C>В можно код клиента посмотреть? Что-то сомнения у меня, что это работает в Windows...
Здравствуйте, elw00d, Вы писали:
E>Здравствуйте, Nikolay_Ch, Вы писали: N_C>>В можно код клиента посмотреть? Что-то сомнения у меня, что это работает в Windows...
E>Используем netcat http://ru.wikipedia.org/wiki/Netcat (для windows можно скачать тут: http://www.securityfocus.com/tools/139)
Т.е. Вы используете какую-то библиотеку, и как она работает Вы не знаете? Тогда надо смотреть именно в NetCat и разбираться с ней.
Re[4]: Можно ли использовать занятый эфемерный порт в bind() ?
Здравствуйте, Nikolay_Ch, Вы писали:
N_C>Здравствуйте, elw00d, Вы писали:
E>>Здравствуйте, Nikolay_Ch, Вы писали: N_C>>>В можно код клиента посмотреть? Что-то сомнения у меня, что это работает в Windows...
E>>Используем netcat http://ru.wikipedia.org/wiki/Netcat (для windows можно скачать тут: http://www.securityfocus.com/tools/139) N_C>Т.е. Вы используете какую-то библиотеку, и как она работает Вы не знаете? Тогда надо смотреть именно в NetCat и разбираться с ней.
Прочитайте описание этой утилиты. Это обычный TCP сервер и клиент в одном флаконе. Может слушать порт, а может подключаться к другому запущенному nc.
Re: Можно ли использовать занятый эфемерный порт в bind() ?
Здравствуйте, elw00d, Вы писали:
E>Допустим есть клиент на TCP сокетах, он подключается к какому-то серверу. У клиенского сокета есть локальный порт, например 52042. После того как этот клиент приконнектился, пробуем на этой же (клиентской) машине поднять какой-нибудь TCP сервер, забиндив его на тот же самый порт 52042. Он поднимается и корректно работает (работает на windows и на linux). Dопрос — какого фига ?
Встречный вопрос — а почему бы и нет? Что мешает? (по крайней мере для того же владельца)
E> Есть предположение что эфемерные порты можно юзать в качестве listening, но вот реального подтверждения не смог найти. Может быть, кто-то в курсе этой темы и может сказать точно ?
Ну я в курсе и могу сказать, что если перед bind() слушающего порта поднять SO_REUSEADDR, то это обеспечивается ядром.
Штатно этот метод предназначен для ситуации, когда новая инкарнация сервера встречается с соединениями, запущенными от старой инкарнации. Но ей при этом пофиг, откуда взялся этот номер порта.
Всё равно конфликта идентификации соединений не происходит.
The God is real, unless declared integer.
Re[5]: Можно ли использовать занятый эфемерный порт в bind() ?
Здравствуйте, elw00d, Вы писали:
E>Прочитайте описание этой утилиты. Это обычный TCP сервер и клиент в одном флаконе. Может слушать порт, а может подключаться к другому запущенному nc.
Вы используете какую-то программу, которая неизвестно как написана и спрашиваете, как она работает?
Кто знает, с какими опциями там инициализируются сокеты? Тот-же SO_REUSEADDR, как уже написали, тоже может быть замешан.
Покопайтесь в ее исходниках или напишите свои и давайте их обсудим.
Re[6]: Можно ли использовать занятый эфемерный порт в bind() ?
Здравствуйте, Nikolay_Ch, Вы писали:
N_C>Здравствуйте, elw00d, Вы писали:
E>>Прочитайте описание этой утилиты. Это обычный TCP сервер и клиент в одном флаконе. Может слушать порт, а может подключаться к другому запущенному nc. N_C>Вы используете какую-то программу, которая неизвестно как написана и спрашиваете, как она работает? N_C>Кто знает, с какими опциями там инициализируются сокеты? Тот-же SO_REUSEADDR, как уже написали, тоже может быть замешан. N_C>Покопайтесь в ее исходниках или напишите свои и давайте их обсудим.
Программа сия — TCP сервер на сокетах. Этого достаточно для того, чтобы обсуждать "почему это возможно", глядя в вывод команды netstat.
А ваши слова выглядят как наезд, призванный оправдать собственный необдуманно написанный ответ после того, как возможное решение найдено.
Re[2]: Можно ли использовать занятый эфемерный порт в bind() ?
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, elw00d, Вы писали:
E>>Допустим есть клиент на TCP сокетах, он подключается к какому-то серверу. У клиенского сокета есть локальный порт, например 52042. После того как этот клиент приконнектился, пробуем на этой же (клиентской) машине поднять какой-нибудь TCP сервер, забиндив его на тот же самый порт 52042. Он поднимается и корректно работает (работает на windows и на linux). Dопрос — какого фига ?
N>Встречный вопрос — а почему бы и нет? Что мешает? (по крайней мере для того же владельца)
E>> Есть предположение что эфемерные порты можно юзать в качестве listening, но вот реального подтверждения не смог найти. Может быть, кто-то в курсе этой темы и может сказать точно ?
N>Ну я в курсе и могу сказать, что если перед bind() слушающего порта поднять SO_REUSEADDR, то это обеспечивается ядром. N>Штатно этот метод предназначен для ситуации, когда новая инкарнация сервера встречается с соединениями, запущенными от старой инкарнации. Но ей при этом пофиг, откуда взялся этот номер порта. N>Всё равно конфликта идентификации соединений не происходит.
Ага, спасибо за информацию. Счс вычитал правда ещё что SO_REUSEADDR может нарушать консистентность сокетной модели, позволяя перехватывать порт у другой программы. http://msdn.microsoft.com/en-us/library/windows/desktop/ms740621(v=vs.85).aspx И для того чтобы этого избежать нужно использовать SO_EXCLUSIVEADDRUSE. В linux судя по всему с этим всё ок, но и механизм несколько отличается.
Re[7]: Можно ли использовать занятый эфемерный порт в bind() ?
Здравствуйте, elw00d, Вы писали:
E>Программа сия — TCP сервер на сокетах. Этого достаточно для того, чтобы обсуждать "почему это возможно", глядя в вывод команды netstat.
Так я и предлагал Вам заглянуть в ее недра. Вы-же отказались...
E>А ваши слова выглядят как наезд, призванный оправдать собственный необдуманно написанный ответ после того, как возможное решение найдено.
Как считаете...
Re[3]: Можно ли использовать занятый эфемерный порт в bind() ?
Здравствуйте, elw00d, Вы писали:
E>Ага, спасибо за информацию. Счс вычитал правда ещё что SO_REUSEADDR может нарушать консистентность сокетной модели, позволяя перехватывать порт у другой программы. http://msdn.microsoft.com/en-us/library/windows/desktop/ms740621(v=vs.85).aspx И для того чтобы этого избежать нужно использовать SO_EXCLUSIVEADDRUSE. В linux судя по всему с этим всё ок, но и механизм несколько отличается.
В юниксах для этого надо было всем участникам выставить SO_REUSEPORT (это другая опция, если сразу не видно)