Правильный дисконнект QTcpSocket

@Гром · Регистрация: 20.03.2009

Author24 — интернет-сервис помощи студентам

Доброго времени суток!

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

Соответственно, имеется два указателя - на QTcpServer и QTcpSocket, общение в обоих режимах происходит через сокет. Имеется возможность в любой момент времени в любом из режимов произвести дисконнект (нажав на кнопку).

Собственно, хотелось бы узнать, как это лучше всего сделать. Есть вариант по нажатию кнопки для сокета вызывать disconnectFromHost, при получении сигнала сокета disconnected вызывать для сокета deleteLater (а если приложение работает в режиме сервера, то заодно вызывать close для сервера). И все вроде бы в этом варианте хорошо, только disconnectFromHost никак не может дойти до высылки сигнала disconnected - очевидно, никак не может закончить прием данных. Видимо, закавыка именно в нем.

Привожу код (а-ля Шлее):

C++ (Qt)

void MyChat::slotReadMessage()
    {
    QDataStream in(Socket);
    in.setVersion(QDataStream::Qt_4_6);
    while(true)
        {
        if (NextBlockSize == 0)
            {
            if (Socket -> bytesAvailable() < sizeof(quint16))
                break;
            in >> NextBlockSize;
            }
        if (Socket -> bytesAvailable() < NextBlockSize)
            break;
        QTime time;
        QString str;
        in >> time >> str;
 
        EdtChatText -> append(str);
 
        NextBlockSize = 0;
        }
    }

Таким образом, у меня два вопроса:
1. Правильная ли моя идея дисконнекта (с учетом двух режимов работы приложения), и не упустил ли я чего-то?
2. Правильно ли я грешу на слот чтения сообщения, и если да, то как его исправить до рабочего состояния?

@Гром · 05.09.2012, 22:05 **[ТС]**

Проблема все еще актуальна.

Maxim Prishchepa · 05.09.2012, 22:51

все верно, банального вызова disconnectFromHost и deleteLeater более чем достаточно (правда я не уверен, на счет close для сервера...) а если не дисконнектит, ищите у себя или бесконечный цикл или проблемы с мьютексом....

@Гром · 06.09.2012, 17:22 **[ТС]**

l_a_m, спасибо, будем искать! Я где-то в сети видел упоминание, мол, у Шлее тут косяк какой-то с лишним break ("читайте лучше Бланшет"), но пока до конца с этим не разобрался.
Для сервера, насколько я понимаю, при закрытии close, при новом создании - listen.

@_SASA_ · 07.09.2012, 16:12

Есть ешЁ возможность обрабатывать ошибки...
Так вот, иногда после SocketError может наступить дисконкт, а может и нет.
Тут нужно обрабатывать что-то одно. Вообще "Правильный дисконект" может
освобождать порт почти сразу, а вот по ошибке - тогда ждать под 90-100 сек.

@Гром 212 / 131 / 28 Регистрация: 20.03.2009 Сообщений: 1,123 Записей в блоге: 16
	05.09.2012, 22:05 [ТС]	2
	Проблема все еще актуальна. 0

Maxim Prishchepa 1936 / 1048 / 109 Регистрация: 29.03.2010 Сообщений: 3,167
	05.09.2012, 22:51	3
	все верно, банального вызова disconnectFromHost и deleteLeater более чем достаточно (правда я не уверен, на счет close для сервера...) а если не дисконнектит, ищите у себя или бесконечный цикл или проблемы с мьютексом.... 1

@Гром 212 / 131 / 28 Регистрация: 20.03.2009 Сообщений: 1,123 Записей в блоге: 16
	06.09.2012, 17:22 [ТС]	4
	l_a_m, спасибо, будем искать! Я где-то в сети видел упоминание, мол, у Шлее тут косяк какой-то с лишним break ("читайте лучше Бланшет"), но пока до конца с этим не разобрался. Для сервера, насколько я понимаю, при закрытии close, при новом создании - listen. 0

@_SASA_ 136 / 140 / 7 Регистрация: 22.08.2011 Сообщений: 485
	07.09.2012, 16:12	5
	Есть ешЁ возможность обрабатывать ошибки... Так вот, иногда после SocketError может наступить дисконкт, а может и нет. Тут нужно обрабатывать что-то одно. Вообще "Правильный дисконект" может освобождать порт почти сразу, а вот по ошибке - тогда ждать под 90-100 сек. 0

Опции темы