Форум: "Сети";
Текущий архив: 2007.01.28;
Скачать: [xml.tar.bz2];
ВнизНеблокирующие сокеты на WinAPi. Найти похожие ветки
← →
DVM © (2006-08-26 19:39) [0]У кого-нибудь есть какой-либо пример использования неблокирующих сокетов. Никак что-то не могу разобраться. Погряз в постоянных проверках возвращаемых функциями результатов для проверки готовности или не готовности сокета.
То ли дело блокирующие сокеты. Но нужны неблокирующие.
← →
DVM © (2006-08-26 19:41) [1]Лучше пример клиента, читающего откуда-нибудь данные (например, с HTTP сервера.)
← →
Eraser © (2006-08-26 20:13) [2]> [0] DVM © (26.08.06 19:39)
> Но нужны неблокирующие.
кому нужны и почему. imho, нужно использовать то, что удобнее в конекретной ситуации.
← →
DVM © (2006-08-26 20:17) [3]
> кому нужны и почему. imho, нужно использовать то, что удобнее
> в конекретной ситуации.
Именно неблокирующие нужны для мгновенного прерывания ожидающей соединения функции connect(). Для блокирующих сокетов даже вызов closesocket() из другого потока не помогает.
← →
Ketmar © (2006-08-26 20:28) [4]> [3] DVM © (26.08.06 20:17)
собственно, а зачем "мгновенно"? висит себе -- и пусть висит. надоест -- само отвалится.
← →
DVM © (2006-08-26 20:54) [5]
> собственно, а зачем "мгновенно"? висит себе -- и пусть висит.
> надоест -- само отвалится.
Не совсем удобно. Представь программу держащую соединения с сотней источников. Скажем, 50 из них недоступны в данный момент. Потоки в циклах пытаются достучаться до недоступных источников. Большую часть времени потоки проводят в ожидании возврата от connect(). При заврешении программы потоки надо прибить. Но прибить корректно, т.е. connect() должна вернуть управление.
Или еще пример. Пользователь добавляет/удаляет такие потоки. Удаление потока должно сразу возвращать управление в программу, а не висеть на WaitFor.
← →
Eraser © (2006-08-26 21:49) [6]> [5] DVM © (26.08.06 20:54)
недавно тут данный вопрос довольно живо обсуждался.
http://delphimaster.net/view/6-1153926991/
Пришли к тому, что для блокирующих сокетов лучший вариант - поступать, как это сделано в Indy, к примеру, убивать сокет из доп. потока.
← →
DVM © (2006-08-26 21:52) [7]
> Eraser © (26.08.06 21:49) [6]
> Пришли к тому, что для блокирующих сокетов лучший вариант
> - поступать, как это сделано в Indy, к примеру, убивать
> сокет из доп. потока.
На деле же для функции connect() это не помогает.
← →
DVM © (2006-08-26 21:54) [8]
> поступать, как это сделано в Indy
с Indy, кстати, такая же проблема. Висит поток на Connect() - прибить сразу не получается.
← →
Eraser © (2006-08-26 21:55) [9]> [7] DVM © (26.08.06 21:52)
странно.. уже довольно дано пользуюсь компонентами от Indy, проблем не наблюдал, все работает четко по таймауту.
← →
DVM © (2006-08-26 22:01) [10]
> странно.. уже довольно дано пользуюсь компонентами от Indy,
> проблем не наблюдал, все работает четко по таймауту.
Попробуй так:
1) Indy в отдельный поток
2) Соединяемся с узлом из той же подсети, что и комп. Узла быть не должно.
3) Из основного потока закрываем сокет, пытаемя уничтожить поток.
У меня реально проходит секунд 10 после команды закрыть сокет и уничтожением потока.
← →
Ketmar © (2006-08-26 22:13) [11]собственно, там же, по-моему, решили так: делать connect() в неблокирующем режиме, а потом переводить сокет в нормальный блокирующий. правда, я до сих пор код не переписал. %-)
← →
DVM © (2006-08-26 22:20) [12]
> а потом переводить сокет в нормальный блокирующий
Помогло? Сейчас проверю у себя.
← →
Ketmar © (2006-08-26 22:32) [13]> [12] DVM © (26.08.06 22:20)
я ж сказал, что код ещё не переписал, ибо ленив. %-)
← →
DVM © (2006-08-27 00:01) [14]
> Ketmar © (26.08.06 22:32) [13]
Я сделал. Вроде работает. Connect() больше не блокирует.
← →
Ketmar © (2006-08-27 00:03) [15]> [14] DVM © (27.08.06 00:01)
ну так отчего бы ему не работать? всё легально, по правилам. %-)
Страницы: 1 вся ветка
Форум: "Сети";
Текущий архив: 2007.01.28;
Скачать: [xml.tar.bz2];
Память: 0.48 MB
Время: 0.037 c