Здравствуйте, все.

FB на W7.
Внутри сети все работает ок, вот при соединении по ADSL2+ (примерно 1.5 Мб/с) каждые 5-10 минут база становится недоступна.
Очень похоже, что просто рвется коннект и сам FB не при чём, так как пользователь внутри сети даже в скайпе пропадает.
Но вот как выяснить, где именно рвется?
Провайдер говорит, что соединение не прерывается.

Dnico, в роутер настроен не отвечать на ECHO.
Да и так понятно, что долгий, по длительности запросов.
Как бы настроить FB, чтобы долгий ответ был допустим?

Dimitry Sibiryakov,
D:\Projects>ping 80.82.55.249 -l 16000

Обмен пакетами с 80.82.55.249 по с 16000 байтами данных:
Ответ от 80.82.55.249: число байт=16000 время=185мс TTL=244
Ответ от 80.82.55.249: число байт=16000 время=186мс TTL=244
Ответ от 80.82.55.249: число байт=16000 время=184мс TTL=244
Ответ от 80.82.55.249: число байт=16000 время=184мс TTL=244

Статистика Ping для 80.82.55.249:
Пакетов: отправлено = 4, получено = 4, потеряно = 0
(0% потерь)
Приблизительное время приема-передачи в мс:
Минимальное = 184мсек, Максимальное = 186 мсек, Среднее = 184 мсек

Dimitry Sibiryakov,
дык речь то пошла о задержке отклика я его и привел, долгий - 186 мс в среднем, бывает до 210
Однако пинг то идет до роутера, а что там дальше с пакетами случается, не совсем ясно.
Сейчас погонял подольше и иногда - "Превышен интервал ожидания для запроса."
Я так понимаю, что коннект с FB при этом может отвалиться.
Какие настройки влияют на допустимый таймаут?

Молочный Александр,
в локалке все работает, то есть сетевая не отваливается. Проблемы только с внешней стороны.

miwaonline, провайдер показал мне лог, в котором несколько дней коннект непрерывный

Спасибо всем за ответы.
Сейчас вот еще погонял пинги, иногда по таймауту превышаются, но клиент при этом не отваливается в течении уже получаса.
Так что, похоже, не таймаут причина...
Что является причиной так и не ясно.
Буду смотреть логи FB и ADSL.
Если что найду - отпишусь.

Dimitry Sibiryakovyushininпровайдер показал мне лог, в котором несколько дней коннект непрерывный

Его "коннект непрерывный" не означает, что пакеты имели возможность непрерывно ходить,

Ох, вот это так трудно объяснить заказчику.
У него своя логика - "интернет есть ведь". Для него это означает, что сайты изнутри открываются.
Все мои объяснения про непрерывность соединения для клиент-серверных систем не достигают сознания.

Dnicoyushinin,
Может поможет, если не устарело ... Тынц
Спасибо за ссылку, как доберусь до сетки, обязательно проверю ADSL

[/quot]
Ну так поставьте сервер БД к нему в локалку, а с удалённым реплицируйтесь через HTTP, раз
уж "сайты открываются".
[/quot]
База то в локалке. Там пользователи радуются жизни с GUI-клиентом.
А вот как только возник удаленный офис, подключающийся к базе, так и возникли проблемы.
И ведь схема то рабочая, даже на ADSL уже неоднократно разворачивал и все ок. Сутками коннект держится.
А тут такая линия попалась... Пригород, там связь - жуть.

NickDeeyushininВсе мои объяснения про непрерывность соединения для клиент-серверных систем не достигают сознания.
И слава богу, что не достигают. Нужно просто уважать людей, и говорить честно. Нужно говорить, что Firebird не умеет работать в таких условиях, которые возникли у нас.
А вы им лапшу про непрерывность соединения для клиент-серверных систем... Зачем?

Странный вывод!
FB отлично работает на ADSL -скоростях при нормальном устойчивом соединении.
И при чем тут лапша?
Клиент-сервер держит коннект. Это как бы аксиома.
Если коннект пропадает, то клиент отваливается.
И где ту лапша?

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

Еще одно техническое откровение!
http(s) не держит соединения, а соединяется при каждом обращении к ресурсу и отключается по окончании передачи контента.
Именно поэтому он, в отличии от клиент-сервера ВЫНУЖДЕН сохранять состояние в данных сессии, печеньках, параметрах запроса и т.д. У него другого способа нет.

Это похоже на работу письмами. А клиент-сервер похож на телефонный разговор.
Если телефона нет, то можно писать письма, но не всегда это нужно.

Вы же не будете утверждать, что телефонное соединение должно прозрачно восстанавливаться после обрыва.

Dimitry SibiryakovDnicoНе все провайдеры способны обеспечить такую связь. Если повезло - будет
работать, нет - нужно менять провайдера.
Или устранить плохой контакт в разъёме телефонной лапши. Или взорвать все трамваи,
проезжающие мимо раз в 5-10 минут. Или перебить всех крыс, жующих витую пару в подвале.

Это то да :-)
Просто линия от города 40 км, а задержки пингов 200мс! Вот я и сетую на связь.
У меня площадка в Германии откликается за 50.

NickDeeПример про https я привёл в качестве технологического аргумента. Безопасность там не страдает. И если кто-нибудь реализует транспортный уровень FB через https (или вообще через нецифровой радиоканал (который является лишь колебанием волн)), то это будет уже не клиент-сервер? Вы в своих программах этого даже не заметите.
tcp-соединение - это абстракция, которая обёрнута протоколом, кодом и пр. Наличие или отсутствие tcp-соединения по воздуху - это просто договор двух сторон на уровне кода и данных. Можно создать 10 tcp-соединений на одно соединение пользователя и качать данные впараллель, если это выгодно по скорости. Можно по одному tcp-соединению пустить все fb-коннекты к одному серверу с одного компа, если вдруг так нужно. И это всё будет клиент-сервер.
Я вот так это понимаю...
Как у вас тут все намешано. Как в шейкере :-)
https не может быть транспортом, это протокол прикладного уровня (так же как и протокол FB), транспорт это - TCP (UDP)
радиоканал - канальный уровень OSI, тоже не транспорт
радиоканал не является "колебанием волн", электромагнитное поле и среда распространения образует ЛИНИЮ связи и лишь с каналообразующим оборудованием (приемником и передатчиком) представляет собой канал
И это всё будет клиент-сервер.

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

Конечно, есть масса модификаций этой архитектуры ( http://megabook.ru/article/Клиент-сервер), которые делают ее пригодной для работы на нестабильных каналах и при очень больших количествах клиентов. Поверьте, я о них о всех знаю и умею использовать.

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

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

rstrelbayushinin,

пробуйте раскомментировать
DummyPacketInterval = 60
в firebird.conf
Дык пишут, что отменили его http://www.firebirdsql.org/file/documentation/release_notes/html/ru/rlsnotes25.html
и собственно http://tracker.firebirdsql.org/browse/CORE-1357
Да и помочь то он мог для "неподвисания" сервера, но никак не от обрыва коннекта.

miwaonlineyushininСейчас вот еще погонял пинги, иногда по таймауту превышаются, но клиент при этом не отваливается в течении уже получаса.
Так что, похоже, не таймаут причина...
Что является причиной так и не ясно.

Так что там насчет Connect on demand в модеме?
У меня пока нет доступа к модему (я снаружи).
Как только выясню, то обязательно напишу в этой ветке.