Проблема с QTcpSocket при обрыве соединения

[sLiva]

Проблема заключается в следующем:
Значит, есть клиент-серверное приложение, работа идет асинхронно, все используемые механизмы сетевого взаимодействия  стандартны. У клиента есть сокет, причем он один создается и инициализируется  при старте клиента. Подключение с сервером осуществляет модальный диалог входа в систему. Работа с сокетом идет нормально, отключается, заново подключается, при обрыве соединения тоже заново подключается, все без проблем. Но когда в главном окне открыт, какой либо модальный диалог, вызванный с помощью QDialog::exec(), и происходит разрыв соединения поведение следующее (при обрыве соединения интерфейс программы блокируется (setEnabled) и вызывается диалог входа в систему который уже в автоматическом режиме пытается восстановить соединение). Так вот если в главном окне не было открыто никакого диалога, то восстановление соединения проходит нормально, но если какой либо диалог открыт, то коннект к серверу происходит нормально, отправляется запрос нормально, а вот сигнал readyRead не генерируется, т.е. сокет адекватно отправляет информацию, но не получает ее, и в результате этого сокет нерабочий, abort() и т.д. не помогают.
У меня возникло такое предположение что это как то связано с передачей управления циклу событий модального диалога, но это так предположение.

Qt 4.3.0, VS2005

Всем кто откликнется заранее спасибо :-)

[ритт]

> работа идет асинхронно
значит ли это, что сокет инитится в отдельном потоке?

скорее всего, сокет у тебя в гуевом потоке, откуда ноги и растут

[Dodge]

1. как присоединен слот к readyRead (директ или очередь)?
2. вы уверенны что сервер вообще чтото отправляет?

[sLiva]

> работа идет асинхронно
значит ли это, что сокет инитится в отдельном потоке?

скорее всего, сокет у тебя в гуевом потоке, откуда ноги и растут

нет сокет инитится в гуевом потоке, в конструкторе главной формы

1. как присоединен слот к readyRead (директ или очередь)?
2. вы уверенны что сервер вообще чтото отправляет?

1. подсоединен в автоматическом режиме, я и не обращал чет внимание на это раньше :-) Сейчас почитал как он работает.
У меня свой класс сокета от стандартного, и в нем как раз и обработчик сигнала readyRead, т.е. соединение работает как очередь, т.к. в одном потоке крутятся.

2. уверен на сто процентом, т.к. дебагил сервак, все норм, запрос приходит, ответ улетает.

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

Спасибо :-))

[ритт]

х**се решение

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

правильнее же разделить логику и гуи по разным потокам

[sLiva]

х**се решение

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

правильнее же разделить логику и гуи по разным потокам

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

Очень интересно, как это разделить логику и ГУИ. У меня сокет клиента имеет что то типа оберток над поддерживаемыми сервером командами, т.е. методы типа login(name, pass), getЧтонибудь() и т.д. сокет сам обрабатывает ответ сервера, и высылает соответствующие сигналы. Сокет создается в главном окне, он один, если с ним работает какой либо виджет то ему отдается указатель на сокет, вот такая логика. Т.е. правильней будет создать для сокета отдельный поток, и чтобы он там жил ?? А что от этого изменится, поток главного окна же не прерывается ?

[ритт]

kalpa's glan?

ладно, а в чём тогда асинхронность?

[sLiva]

kalpa's glan?

ладно, а в чём тогда асинхронность?

имелось ввиду асинхронность работы сокета, в промежуток времени от момента запроса и ответа гуи не блокируется, т.е. использование сигналов вместо блокирующих ГУИ waitFor... :-))

[ритт]

сразу представил секетутку-бляндинку, 10 раз кликающую, например, "закрыть" в промежутках времени от моментов запроса и ответа...

если каждый такой клик добавляет командный пакет в очередь, то придётся ещё и компрессию комманд реализовывать

кинуть ссылку на глан или сам найдёшь?

[sLiva]

сразу представил секетутку-бляндинку, 10 раз кликающую, например, "закрыть" в промежутках времени от моментов запроса и ответа...

если каждый такой клик добавляет командный пакет в очередь, то придётся ещё и компрессию комманд реализовывать

кинуть ссылку на глан или сам найдёшь?

спасибо, почитал про глан, интересный проект