Сокеты, таймаут

← →
Vitaliy © (2006-07-23 22:16) [0]

Подскажите пожалуйста, как изменить таймаут на функцию connect для TCP сокета. Дело в том, что если я пытаюсь соедениться к компьютеру на котором не установлен ServerSocket, то клиентский сокет блокируется на 21 секунду. Как уменьшить это время?
P.S. Использую стандартные сокеты (http://www.delphikingdom.com/asp/viewitem.asp?catalogid=1021)

← →
Сергей М. © (2006-07-24 08:32) [1]

> Как уменьшить это время?

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

← →
Ketmar © (2006-07-24 21:24) [2]

>Сергей М. © (24.07.06 08:32) [1]
мучают подозрения, что "как" всё-таки есть. но доказать не могу. %-)

← →
Сергей М. © (2006-07-25 08:13) [3]

> Ketmar © (24.07.06 21:24) [2]

> доказать не могу

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

← →
Ketmar © (2006-07-25 13:27) [4]

>Сергей М. © (25.07.06 08:13) [3]
понятно, что от таймаута на получение пакета подтверждения (скорость линии в данном случае не рассматриваем). вот меня и мучают подозрения, что этот таймаут можно регулировать. на закрытие можно, это я использую. а на соединение как-то не приходилось, вот и теоризирую. %-)
точнее, жду, пока придёт кто-то знающий и снисходительно всё расскажет. %-)

← →
Сергей М. © (2006-07-25 13:30) [5]

Ну, положим, в реестре есть некие соответствующие (по смыслу) параметры.

Но действуют они, imho, отнюдь не на конкретный connect(), а на интерфейс в целом ... с момента инициализации объект а, его предоставляющего, при старте системы как таковой.

Прикажешь реестр править ?)

← →
Ketmar © (2006-07-25 16:23) [6]

>Сергей М. © (25.07.06 13:30) [5]
понятно, что в реестре много чего есть. но меня мучают смутные подозрения насчёт наличия возможности управления через WSAIoctl(). однако искать не пойду -- тогда интересный разговор закончится. %-)

← →
Сергей М. © (2006-07-25 16:41) [7]

> Ketmar © (25.07.06 16:23) [6]

Э-э-э...

Вылупился я в кои-то веки, как баран на новые ворота, сюда:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winsock/winsock/wsaioctl_2.asp

Куда уж, казалось бы, предметней будет ссылка насчет упомянутой тобой WSAIOctl() ..

Ввожу там, дуб я дубом, модель поиска "timeout" - и получаю полный отлуп. Ну нет, понимаешь ли, в описании сей ф-ции ни малейших намеков на тайм-ауты !
Мне что, в дурку пора ?)

← →
Ketmar © (2006-07-25 18:28) [8]

>Сергей М. © (25.07.06 16:41) [7]
э-э-э... ну, я же не сказал, оно именно там. если бы я это точно знал -- я бы так и написал. а были только подозрения. "подозрение не есть уверенность, можно и ошибиться" (ц) в других функциях управления сокетами я тоже ничего не нашёл по этому поводу. но вот "нутром чую", что должно быть что-то. (прим.: этимологию слова "нутро" пояснить не могу)

зыж при помощи WSAIoctl() как минимум устанавливаются таймауты для keep-alive пакетов. что важно, ибо по умолчанию обрыв соединения регистрируется через совершенно неприличное время. %-)

← →
Eraser © (2006-07-25 19:18) [9]

> [0] Vitaliy © (23.07.06 22:16)
> Подскажите пожалуйста, как изменить таймаут на функцию connect
> для TCP сокета. Дело в том, что если я пытаюсь соедениться
> к компьютеру на котором не установлен ServerSocket, то клиентский
> сокет блокируется на 21 секунду. Как уменьшить это время?

можно глянуть исходники Indy.. ведь там же как-то это реализовано..

← →
Ketmar © (2006-07-26 00:08) [10]

>Eraser © (25.07.06 19:18) [9]
честно? просто не пользую индейцев. с ходу могу предположить, что там таки неблокирующий режим для этого используют. найду архив с индейцами -- гляну. %-)

← →
Eraser © (2006-07-26 02:19) [11]

> [10] Ketmar © (26.07.06 00:08)

> честно?

угу )

> найду архив с индейцами -- гляну. %-)

я попробовал это сделать.. всмысле глянуть.. так и не хватило терпения докопаться до того места, где используется API )) намудрено у них там все ))

← →
Сергей М. © (2006-07-26 08:45) [12]

> Vitaliy © (23.07.06 22:16)

Вот фрагмент справки к ф-ции select(), предусматривающей возможность задания таймаута ожидания событий:

The parameter writefds identifies those sockets which are to be checked for writability. If a socket is connecting (nonblocking), writability means that the connection establishment successfully completed

← →
Ketmar © (2006-07-26 14:01) [13]

>Сергей М. © (26.07.06 08:45) [12]
select() -- это круто. только в блокирующем режиме connect() не вернёт управление, пока не соединится или не обломится. так что select() демократию не спасает.
как сделать через неблокирующий режим -- я знаю. мне с блокирующим интересно. %-)

← →
umbra © (2006-07-26 17:37) [14]

в инди сам процесс коннекта происходит в отдельном потоке, а основной поток крутится в цикле, дожидаясь таймаута. Если таймаут наступил, а поток не завершился (соединение не установлено), то возбуждается EIdConnectTimeout. Вся эта кухня для инди 10 находится в модуле IdIOHandlerStack.pas в методе TIdIOHandlerStack.ConnectClient

← →
Ketmar © (2006-07-26 19:10) [15]

>umbra © (26.07.06 17:37) [14]
ясно. благодарю за информацию. что-то вроде этого я и предполагал. %-(

← →
Сергей М. © (2006-07-27 09:52) [16]

> Ketmar © (26.07.06 14:01) [13]
>
> >Сергей М. © (26.07.06 08:45) [12]
> select() -- это круто. только в блокирующем режиме connect()
> не вернёт управление

IMHO, ты свихнулся на этом блок.режиме)

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

← →
Ketmar © (2006-07-27 10:11) [17]

>Сергей М. © (27.07.06 09:52) [16]
таки да. это форма "бзика". %-) ну вот есть у меня резкая антипатия к неблокирующему. причём я уже и не помню, из-за чего она возникла. есть подозрения, что из-за моего в своё время неумения с ним толком работать.

к тому же блокирующий реально удобнее -- нет лишних проверок и асинхронных вызовов. меня всем устраивает, кроме connect(). %-)

зыж глянул в свой старый софт. тоже работаю с блокирующим режимом, для проверок на отсутствие блоков в нужных метсах использую select(). извращенец? %-)

> меня всем устраивает, кроме connect()

Предлагаю разумный компромисс - connect() выполняй в неблок.режиме, а после установления коннекта продолжай работать так как тебе удобно, т.е. в блокирующем.

Ы ?

я, кстати, как раз об этом думал. только -- а резве можно сокет туда-сюда переводить после connect()? (это так, вопрос "в воздух", сам проверю, натурально %-).

однако странно, что для connect() не предусмотрено настроек. или предусмотрены, но я всё-таки куда-то не туда рою? это уже так, патологическая любознательность. %-)

зыж для себя-ненавистника удобств придумал вариант: делать connect() вообще в отдельном новом потоке. %-))

> резве можно сокет туда-сюда переводить после connect()?

Можно. Хоть до хоть после)
Главное понимать при этом, что и зачем)

> это уже так, патологическая любознательность

Тогда сходи , к примеру, на book.itep.ru, почитай про протокол TCP и вникни, что, как, когда и зачем происходит в момент установления коннекта.

Уверяю тебя - весьма пользительная инф-ция, хотя бы для общей эрудиции по сабжу.

> делать connect() вообще в отдельном новом потоке

Задница - она терпит геморрой до определенных пределов)))

>Сергей М. © (27.07.06 15:03) [22]
видимо, так и перепишу. с отдельным потоком для connect() -- это шутка была. %-)
просто пока руки не доходят переписывать (читай: лениво %-).

а закрывать сокеты других потоков всё равно буду. вот. так удобнее. %-)

> видимо, так и перепишу. с отдельным потоком для connect()

Да на здоровье)
Борланд тоже не брезгует пользовать блокирующий accept() в отдельном потоке.
Между accept() и connect() в этом плане невелика разница.

есть. наличие клиента для accept() можно определить. и не звать accept(), когда никого нет. а connect()... ну, читаем веточку... %-)

Сокеты, таймаут Найти похожие ветки