QTcpSocket::write() — как гарантировать пересылку данных одним пакетом?

Question

[Павел]

Добрый день.



Я новичек в сетевом программировании, но все же.



Пишу клиент-серверную систему. Есть qt клиент и qt сервер. Клиент отправляет запрос (json), сервер обрабатывает запрос и генерирует json ответ.



На стороне сервера отправка данных реализована через метод socket-> write(data), где data — это строка.



На стороне клиента при получении данных вызывается метод slotReadyRead(), подключенный к сигналу readyRead().



Данные считываются методом socket->readAll().



Но вот проблема, когда сервер передаёт небольшую строку, то клиент принимает ее полностью. Если большую строку (большой Джейсон), то строка передаётся частями. То есть один вызов сигнала readyRead не означает получение ПОЛНОГО сообщения от сервера, насколько я понимаю. Отсюда вопрос, как за один раз передать ВСЮ БОЛЬШУЮ строку?

Answer 1

[AMDmi3]

Никак. TCP — это поток данных, он не разбивается на сообщения. Когда нужны оные, передают сначала длину, потом тело каждого очередного сообщения.

Answer 2

[rozhik]

Никак. Есть такая штука, называется MTU . Пакет не может быть больше MTU в принципе (обычно это около полутора килобайт).
Вам в любом случае нужен протокол верхнего уровня, чтобы общаться сообщениями а не потоком (в принципе можно конечно скобочки считать, но это не решение). Часто между сообщениями бросают строку, которая гарантированно не может попасть в данных или передают перед сообщением размер.
Кпк начинающему я бы порекомендовал qtWebsocket.

Comments

[Павел]

Все равно не понимаю. Если я передам сначала размер сообщения (длину строки), а она передастся не полностью, то что изменится?

Спасибо, за ссылку. Буду смотреть.

Answer 3

[rozhik]

а она передастся не полностью, то что изменится?
изменится то, что Вы будете знать что данные еще не все пришли, и нужно читать еще.

Серьёзно — смотрите на кютивэбсокеты, они с потоками хорошо дружат и еще 100 плюсов есть. Я когда-то заманался бить студентов по руkам за кривые решения с raw-tcp.

Comments

[Павел]

Ок. Хорошо хоть есть кому по рукам бить и говорить «но но». Ещё раз спасибо

[Павел]

все же подумал и решил проблему следующим образом: на стороне сервера при отправке сообщения к сообщению добавляю признак конца строки. на стороне клиента при приеме сообщения делаю:

QString response;

    while(1)
    {
        response += QString(m_pTcpSocket->readAll());

        if (response.contains("\n"))
        {
            break;
        } else
        {
            m_pTcpSocket->waitForReadyRead(100);
        }
    }

насколько это правильно — не знаю. но работает.

[Максим Мосейчук]

Если вместе с концом строки придёт ещё что-то? Да и в qt чтение из сокета проще реализовать через сигнал\слот.

[rozhik]

Если вместе с концом строки придёт ещё что-то? — будет ку. Нужно делить по этому символу. И перед следующим чтением считать хвост началом следующей строки.
Да и в qt чтение из сокета проще реализовать через сигнал\слот.
Вот это здравая мысль. Я вообще удивился, что человек, пишущий на qt, использует блокирующее чтение.

[Павел]

По поводу сигнал/слот: так и реализовано. Этот цикл запускается в слоте, подключенному к readyRead. Но одна высылка сигнала readyRead не гарантирует доставку всего сообщения (читай json), а говорит только о том, что пришла первая порция данных, а остальную надо ждать.

По поводу «если с концом строки придет ещё что-то». В моём случае не придёт. Сервер отвечает на запросы клиента и самостоятельно ничего не посылает. То есть передаётся одно сообщение, а не несколько сообщений, разделенных символом конца строки

Answer 4

[Максим Мосейчук]

Берёте платформенно-независимый тип данных. К примеру quint64.
Вычисляете размер сообщения, сохраняете в quint64.
Отсылаете эту переменную, затем сообщение.

На другом конце:
if(bytesAvailable() < sizeof(quint64)) return;

Если больше, считываем quint64, в котором будет размер следующего сообщения. Ну и ждём, пока придут остальные байты, >= полученного значения.

И данные лучше сериализовать через QDataStream

Comments

[Павел]

Через datastream не вариант. Так как с сервером общается не только qt приложение-клиент. Но и джава клиент (андроид). А разбираться с форматом datastream не хочется