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 в модеме?
У меня пока нет доступа к модему (я снаружи).
Как только выясню, то обязательно напишу в этой ветке.