В косвенное продолжение темы коротких коннектов встал вопросик.

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

А суть в чем.
Есть у клиента коннект и две транзакции. Одна читает - readonly и держится она постоянно, и есть пишущая - короткая, создается только для записи. Есть кучка сессионных переменных и временных таблиц (видимых в рамках сессии).
Рвется связь - кратковременно - меньше секунды - чаще всего из-за балансировки нагрузки на каком-то маршрутизаторе.
Клиент отваливается. На сервере остается висяк, который можно убить через mon$attachments, но сначала нужно угадать какой, и он (attacment) не знает что клиент помер...

Можно перепилить клиента чтобы он делал короткие коннекты на чтение, но тогда встает вопрос падения FB (о котором я писал раньше) и теряется прелесть временных таблиц.

Вопрос.
Существуют ли какие-то библиотеки/инструменты/решения чтобы повысить устойчивость соединения - не отрывать клиента при кратковременных сбоях сети.
Естественно не стоит вопрос вернутся в пишущую транзакцию - это не критично, можно сделать вторую попытку, но как сохранить соединение по чтению или воткнутся в старое, так чтобы сохранить сессионные настройки.
Ну или хотя бы не рвать связь при коротких обрывах (меньше пары секунд).
Да, и со стороны сервера - можно ли узнать что клиент отвалился?
в логе будет ошибка
INET/inet_error: send errno = 10054
но это не решает проблему...

Возможно вопрос глупый, а может уже есть какие-то библиотеки или идеи?
Самое забавное, что тонкого клиента под FB я не нашел.

Симонов Денисчто значит не нашёл тонкого клиента под ФБ? Тонкий клиент это архитектурное решение, а не какая-то готовая библиотека
да, я это понимаю.

Мимопроходящий01.02.2019 16:40, Игорь-PicoMed пишет:
> Клиент отваливается. На сервере остается висяк

http://www.ibase.ru/keepalive/


все это настроено, но проблему обрыва не решает

Всем спасибо за дельные советы.

Кратко подводя итоги.
1. По России шнур выдергивали и все работало, в Казахстане соединение падает постоянно, особенно когда сервер в Астане а подключение откуда-нибудь из Усть-Каменогорска. Причину так и не нашли. Есть мрачное предположение что с законом Яровой и в России начнется та же фигня.
2. Терминальное решение хорошо, но каналы нужны оооочень толстые
3. zebedee гоняли лет ...надцать назад. Думал что проект помер уже. Применяли для заказчиков-параноиков которые боялись перехвата по сети. Заметной устойчивости в стародавние времена он не добавлял.
4. тестили аппаратный VPN (не в РК) - действительно хорошо и стабильно, но дорого, за программные решения - спасибо - попробуем
5. за комментарии про трешку - тоже спасибо
6. много серверов и репликация, грустно как-то, особенно когда сервер на 2-3 клиента и серверов под сотню. Этот зоопарк потом замучишься обслуживать. Очень надеялся от этого уйти. Всем "облако" подавай... и центральные сервера, дабы на сисадминах экономить
7. кэширование "все и вся" в локальных таблицах - тоже странное решение (чем-то dbf-ами попахивает или BDE). Зачем тогда сервер? Зачем мощные инструменты базы, если все поисковые задачи будет выполнять клиент в локальных таблицах. Да и делать поиск по паре десятков тысяч строк на дерьмовеньком локальном компе [пример - поиск города в КЛАДР по контексту названия]- то еще удовольствие (и это не считая время на подгрузку кэша).
8. Трехзвенка c FireBird - идея давно в воздухе, но мне ничего приличного не попадалось, всё что крутится - вокруг MS SQL - может посоветуете что-то под FB?