тогда так:
> определивших разрыв в долю секунды

механизм определения опиши (кратко) и найдем, то место, где мы недопонимем друг друга...

> механизм определения опиши (кратко)
кртк, пдмй чт присхдт н Cmd.Execute.

ясн

> sniknik ©   (16.10.13 17:21) [37]
> > вот такую ссылку:
> по ней все с точностью до наоборот, в простое посылка проверочных
> пакетов не обязательна (даже по умолчанию отсутствует)

Коль, позволю себе не согласиться с твоим утверждением :)
Дело в том, что сокеты Windows, это не совсем полная трактация беркли.
В частности сокет может получить уведомление о разрыве соединения и без выставления параметров SO_KEEPALIVE, которое ему направит драйвер сетевой карты, получивший уведомление о том что кабель выдернули. Правда это конечно не означает то, что данное уведомление получит вторая сторона канала.

Да, ну и по поводу этого вашего ADO - Легыч меня сегодня с пристрастием пинал в курилке, как оно это все работает, так вот как работает ADO и почему оно не получает дисконнекта там, где обычная реализация сокета получает - сие мне не ведомо :)

> В частности сокет может получить уведомление о разрыве соединения и без выставления параметров SO_KEEPALIVE
не вижу ничего противоречащего, ну не стоит параметр для постоянного "прозвона", но при начале работы (передаче данных) он что пакеты не шлет, ответы/ексепты не анализирует?... вот и узнали. вот и "может получить". все сходится.

> и почему оно не получает дисконнекта там, где обычная реализация сокета получает
обычная реализация сокета одна... ну по сути, написана "дядей мелкософтом", а драйвера пишут чуть ли не каждый желающий... причем обмен(сокет/мемори/пайпы/...) идет внутри этих драйверов... не наводит на мысли?
чисто ADO-шный (не зависящий от реализации драйвера) таймаут будет только в асинхронном режиме, ИМХО, т.к. в этом случае драйвер работает в отдельном потоке, и ADO не блокирует, т.е. есть шанс проверить/снять зависший поток (хотя делает он это или нет хз. ломает проверять... ну надо найти для начала зависающий драйвер, поставить для него сервер, ... да ну его нафиг, пусть остается просто домыслами).

> В частности сокет может получить уведомление о разрыве соединения
> и без выставления параметров SO_KEEPALIVE, которое ему направит
> драйвер сетевой карты, получивший уведомление о том что
> кабель выдернули. Правда это конечно не означает то, что
> данное уведомление получит вторая сторона канала.


Ээээ, секундочку!
Клиент - Свич - Сервер. Кабель был обрезан между свичём и сервером. Как клиент узнает, что ёк?

> Как клиент узнает, что ёк?
слова "гарантированная доставка" ни о чем не говорят? вот представь стреляешь из автомата по мишени... ты - клиент, мишень - сервер, пули - данные (пакеты), задание переложить весь рожок "на сервер"... с гарантией! т.е. выстрелил, тут же бинокль к носу, проверяешь для гарантии, попал? да - го то следующий выстрел, нет - добавляешь к рожку такую же пулю которой смазал и повторяешь (3 раза).
и вот вопрос, как клиент (ты) узнает, что мишень пропала?

протокол, это не почта России, типа послал, и тишина..., это взаимодействие... прекратилось/испортилось в нем что-то, как не узнать?

> Кабель был обрезан между свичём и сервером

no route to host - disconnect

дельта времени, за которую мы об этом узнаем оч мала. но имхо, возможны ситуации, когда эта дельта будет больше, тот самый таймаут, но это для прикладного уровня, опять же имхо... (ситуацию пока не придумал ;) )

о придумал, клиент льет данные на сервер, на магистрали авария, и пакеты идут 50x50, но идут, поднимается нагрузка на вспомогательный трафик, но обмен все еще идет. потом бац! разрыв как в [46].
на транспортном уровне все понятно - сервер не доступен, но что делать софту? перед разъединением, по идее, он должен некоторое время попытаться восстановить соединение (на прикладном уровне). Вот он его и делает некоторое время (те таймаут времени, заложенном программистом), не получилось? полный дисконнект.

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

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

> слова "гарантированная доставка" ни о чем не говорят?


Гарантированная доставка - это когда движуха есть. А я соединение установил и уехал в Углич на рыбалку.

> А я соединение установил и уехал в Углич на рыбалку.
тогда смотри ссылку которую сам дал... установлен параметр, значит, продолжая аналогию, есть специальный человек который время от времени "зырит" в бинокль на предмет на месте ли мишень... не установлен, считай этот человек в "отпуске".

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


Вот. И теперь мы плавно подходим к реализации драйверов доступа к БД. Вот почему никакая падла этот параметр не взводит в случае TCP?

> Вот почему никакая падла этот параметр не взводит в случае TCP?
а по большому счету тебе он нафига? вот ты соединился (что-то посмотрел с сервера), и уехал в Углич на рыбалку... завтра сеть "упала", и "поднялась" через 2 недели, только за полчаса до твоего возвращения... ты вернулся и снова что-то посмотрел, падения даже не заметил... смысл получать эксепты/загружать канал служебной инфой (платить за трафик если сеть-инет такой) все 2 недели бездействия??? при том что первое же активное действие тут же получит статус сети.

dmadma
В AdoCommand или AdoDataSet как вы там запрос выполняете, есть таймаут, вот его надо смотреть, а не AdoConnection.
Для MySql есть свои компоненты, с ними получше работать чем с ADO.

Пользуюсь MySQL + AnyDAC.
Но тоже интересно, как специалисты рекомендуют обставлять проблему.
Пока вообще никаких специальных мер не принимаю.
Что несколько смущает.

Предлагаю запихать коннект в отдельный поток, и перед тестом передавать управляющей переменной что соединение отключено. В потоке сделать тест если он зависает, то управляющая переменная уже со значением False если все гут то соединение будет  практически  мгновенными передаст упр. переменной статус true.

Вернее не соединение, а "прозвон"