Контроль подключения к Интернет

← →
igorx © (2002-11-05 10:54) [0]

Моя программа связывается с сервером через Интернет. На случай отсутствия связи в ней предусмотрен таймаут. Но вот проблема: при первом подключении, когда автоматически начинает отрабатывать набор номера телефона провайдера, проверка пароля и т.п. таймаут, понятно, успевает произойти.
Подскажите, как обойти указанную проблему не убирая контроля корректности подключения при первом входе в Интернет?

← →
Digitman © (2002-11-05 11:01) [1]

Код приведи свой

← →
igorx © (2002-11-05 11:07) [2]

Код-то довольно большой... :)
Ну, для примера:

Timer.Enabled:=True;
Socket.Open;
Timer.Enabled:=False;

...

procedure TimerOnTimer(Sender: TObject);
begin
//Обработка тайм-аута
end;

Так вот, необходимо, чтобы только!!! в вышеописанном случае таймаут не отрабатывался

← →
Reindeer Moss Eater (2002-11-05 11:16) [3]

Так кто заставляет обрабатывать-то? Не обрабатывай

← →
igorx © (2002-11-05 11:21) [4]

Правильно, но как мне определить, что произошло именно то событие (см. выше), которое не надо обрабатывать? Остальные то надо.

← →
Reindeer Moss Eater (2002-11-05 11:28) [5]

Не запускай свой таймер пока не выполнится дозвон.

← →
igorx © (2002-11-05 11:31) [6]

А как мне определить, что дозвон окончился или вообще происходит? Программа для ламеров, там возможны любые варианты (от уже установленной связи с Интернет до полного отсутствия подключения в принципе)

← →
Reindeer Moss Eater (2002-11-05 11:31) [7]

А как мне определить чем ты звонишь?

← →
igorx © (2002-11-05 11:34) [8]

Так я и не знаю, чем звоню :)
Программа для широкого распространения в Интернет, звонит могут чем угодно (или ничем вообще)

← →
Reindeer Moss Eater (2002-11-05 11:36) [9]

Ты хочешь сказать что это не твоя программа?

← →
igorx © (2002-11-05 11:39) [10]

Программа моя, пользователи программы (и их компьютеры) не мои :)))

← →
Reindeer Moss Eater (2002-11-05 11:43) [11]

Кто инициирует дозвон к провайдеру, если доступ по DialUP?

← →
igorx © (2002-11-05 11:45) [12]

Клиент у себя на компьютере

← →
Reindeer Moss Eater (2002-11-05 11:50) [13]

Если твоя программа не заморачивается с установлением соединения (считает, что оно есть), то обрабатывай событие OnError.

← →
igorx © (2002-11-05 11:54) [14]

Ну, если на то пошло, то не только OnError, а прежде всего try except, т.к. сокетный Open чаще вываливается с исключением (как-то прочитал в FAQ). Впрочем, у меня есть и то, и другое. Но мой двухгодичный опыт работы с сокетами показывает, что на практике бывают ситуации, когда они просто "умирают". Тут без тайм-аута не обойтись. Вопрос в том, как определить, что сокет не ждет ответа, а подключается.

← →
Reindeer Moss Eater (2002-11-05 11:57) [15]

Забыть про свой печальный двухгодичный опыт и перейти к использованию других библиотек. Например Indy 9.x

← →
igorx © (2002-11-05 11:58) [16]

В Indy сокеты только блокировочные, а мне нужне неблокировочные :)

← →
Reindeer Moss Eater (2002-11-05 12:00) [17]

ICS

← →
igorx © (2002-11-05 12:02) [18]

А че такое ICS?

← →
Digitman © (2002-11-05 12:03) [19]

Ставь Timer.Enabled =True в событие OnConnecting()

← →
Reindeer Moss Eater (2002-11-05 12:05) [20]

Два года говоришь?
http://www.rtfm.be/fpiette/icsuk.htm
А вообще я не находил веских причин не использовать blocking режим ни в GUI приложениях, ни в сервисах.

← →
igorx © (2002-11-05 12:09) [21]

А если он повиснет чисто на Open? И потом, такая ситуация может быть не только на Open. Например, моя программа периодически (несинхронно) должна получать от сервера некие порции данных. Если их долго нет, она шлет серверу маяк и ждет ответа. Если ламер-пользователь за это время каким-то образом успел выгрузить поддержку телефонного соединения, процесс подключения начнется сначала с печальным сообщением об ошибке тайм-аута (нет ответа на маяк в приемлимое время) которой на самом деле нет.

Блокировочный режим - значит работа с потоками. Это достаточно большое усложнение логики работы программы, которая и так достаточно непроста. Кроме того, я эту программу получил "по наследству" и такой кардинальный переход заставит меня, скорее всего, переписать ее заново, что сложно и ненужно. Кроме указанной проблемы с ней, вроде бы, все в порядке. Мне бы узнать, как определить режим подключения :)))

← →
Reindeer Moss Eater (2002-11-05 12:22) [23]

Блокировочный режим вовсе не требует работы с потоками

У меня программа асинхронная, т.е. по сокету приходят команды и данные инициирующие определенную реакцию независимо друг от друга. Я не могу, например, ждать после SendBuf реакцию другой стороны, я сразу должен быть готов к приему следующей команды.
По поводу адреса, который ты любезно скинул - там все по-французски, что ли? А хотя бы по-английски ничего нет?

← →
Reindeer Moss Eater (2002-11-05 12:34) [25]

Так это ты описал серверный компонет. В TidTCPServer потоки работающие с клиентами реализованы внутри класса.

У меня и сервер и клиент работают асинхронно. Я так понимаю, Indy ведь должны быть и на той, и на другой стороне? И тут еще вопрос: как бы Indy не были хороши, разве периодического "умирания" связи в общем случае можно избежать? Плохая связь, провайдеры и проч. Все равно, я бы не решился бросать программу в сеть без таймаута, на одних try"ях и OnError"ах. Ламеры есть ламеры, связь есть связь. Так что проблема все равно останется.

← →
Reindeer Moss Eater (2002-11-05 12:49) [27]

В Indy реализована поддержка таймаута при чтении/записи/соединении.
Что находится "на другой стороне" клиентской программе все равно.

Правильно, но на другой стороне должен стоять блокировочный сокет, что нежелательно (см.выше). И потом, чем тайм-аут Indy отличается от моего? Indy также дадут ошибку в моей ситуации, что не нужно :)

← →
Reindeer Moss Eater (2002-11-05 12:56) [29]

Клиент Indy начав коннект без установленной связи сгенерит исключение. А если связь есть и если соединение не будет установлено в заданное время возникнет другое исключение.

Ну как бы там ни было, кнопку улучшения качества связи ты не изобретешь.

Я уже понял, что Indy намного лучше :))) Ладно, действительно, может в следующей версии программы я на них и перейду. Ну а со стандартными сокетами Borland никак нельзя определить, находятся ли они в состоянии соединения с сетью или срабатывание тайм-аута есть результат ошибки?

Контроль подключения к Интернет Найти похожие ветки