Форум программистов [Powered by Invision Power Board]

Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > С/С++: Кроссплатформенное программирование, Qt/Gtk+/wxWidgets > [Qt] QIODevice чтение данных

Автор: null56 1.8.2009, 13:44

Использую методы данного класса, так как он является родственником QSslSocket, поэтому это получается единственный способ чтения и записи от/к сокету...
Как я вижу потоковое взаимодействие с объектом:
1) поступают некоторые данные
2) после поступления конечного сообщения, генериться сигнал readyRead, говоря о том, что доступна новая строка (line)
3) строку можно извлечь методом readLine, указав количество байт для извлечения

Код


qint64 readLine ( char * data, qint64 maxSize )
QByteArray readLine ( qint64 maxSize = 0 )

или прочитав все накопишиеся данные в устройстве методом

Код


QByteArray readAll ()

Если я правильно понимаю работу с данным классом, то не понимаю одного - OpenMode

Код


QIODevice::NotOpen    0x0000    The device is not open.
QIODevice::ReadOnly    0x0001    The device is open for reading.
QIODevice::WriteOnly    0x0002    The device is open for writing.
QIODevice::ReadWrite    ReadOnly | WriteOnly    The device is open for reading and writing.
QIODevice::Append    0x0004    The device is opened in append mode, so that all data is written to the end of the file.
QIODevice::Truncate    0x0008    If possible, the device is truncated before it is opened. All earlier contents of the device are lost.
QIODevice::Text    0x0010    When reading, the end-of-line terminators are translated to '\n'. When writing, the end-of-line terminators are translated to the local encoding, for example '\r\n' for Win32.
QIODevice::Unbuffered    0x0020    Any buffer in the device is bypassed.

Собственно пример
1) в eventLoop в потоке висит сокет и по таймеру (скажем раз в 5 секунд )проверяет поступившие данные.... то есть он не подключен на реакцию readyRead, что позволит ему накопить некоторый объем данных
2) со стороны клиента я высылаю, за данный промежуток несколько сообщений

Вопрос:
Как должен вести себя объект QIODevice?
Он должен стирать предыдущее сообщение или дописывать в конец предыдущего?
Просто, какой бы я режим не пользовал, а имеено

Код


QIODevice::ReadWrite

, а так же

Код


QIODevice::ReadWrite | QIODevice::Append

разницы не вижу.... в обработчике таймера делаю readLine, мне возвращается конкатенация всех поступивших за данный период сообщений.... какой бы режим я не пользовал, хоть просто запись-чтение, хоть добавляя append
Тогда в чем разница? как должно накапливаться сообщение в устройстве?

Заранее благодарен за помощь всем откликнувшимся за помощь

Автор: SABROG 1.8.2009, 14:49

Оно накапливается до размера буфера, а потом из буфера стирается столько данных сколько ты прочитал. Если ты буфер не читаешь и он полностью заполнен, то передача данных сервером прекращается пока ты не считаешь данные. Я думаю режимы открытия устройства мало влияют на сокеты. Хотя было бы интересным узнать какие из флагов вообще работают. Например, если поставить QIODevice::ReadOnly будет ли возможным записать что-либо в сокет?

Автор: null56 1.8.2009, 20:04

Если на серверной части сделать

Код


setSocketDescriptor(socket_descriptor, QAbstractSocket::ConnectedState, QIODevice :: ReadOnly)

то уже на этапе обемена ключами получаем в консоли

Цитата

QIODevice::write: ReadOnly device

Про WriteOnly соответственно

Код


QIODevice::write: ReadOnly device

при обмене ключами.... другими словами эти флаги работают

Но я просто предполагал, что в случае записи, сохраняется последняя в устройстве строка, а при добавлении (Append) они уже конкатенируются... но видимо ошибся... просто не вижу разницы, что с write, что с append
Можно тролям написать узнать... хотя как правильно вопрос сформулировать.. поддержка стабильно отвечает по понедельникам

Использование QIODevice::Unbuffered, я так понимаю, тоже не вариант... тогда вообще данных не получу, надо сразу будет их читать по слоту....

Автор: SABROG 1.8.2009, 20:07

Цитата(null56 @ 1.8.2009, 20:04

)

QIODevice::Unbuffered

А этот флаг не будет работать для sequential устройств.

Автор: kuzulis 3.8.2009, 08:04

Цитата

Цитата(null56 @ 1.8.2009, 20:04 Найти цитируемый пост)
QIODevice::Unbuffered

А этот флаг не будет работать для sequential устройств.

не, по моему работает даже если у-во sequential ! Т.е. буфер отключается ! Я это "заметил" при реализации библиотеки http://www.prog.org.ru/topic_9537_0.html

Цитата

Как я вижу потоковое взаимодействие с объектом:
1) поступают некоторые данные
2) после поступления конечного сообщения, генериться сигнал readyRead, говоря о том, что доступна новая строка (line)
3) строку можно извлечь методом readLine, указав количество байт для извлечения

1. Да
2. Не конечного сообщения - а хотябы одного байта! (вроде)
3. Не факт что извлечете всю строку, т.к. эти методы readLine, raad, readAll читают только то, что уже имеется в буфере! т.е если нам нужно прочитать 100 байт, а пришло 50 - то прочитается 50 .. т.е мы "недочитаем" .. тем более что readAll читает максимум 4096 байт

ЗЫ:
Если не ошибаюсь

Добавлено через 3 минуты и 47 секунд

Цитата

Если на серверной части сделать
Выделить всёкод C++
1:

setSocketDescriptor(socket_descriptor, QAbstractSocket::ConnectedState, QIODevice :: ReadOnly)

то уже на этапе обемена ключами получаем в консоли
Цитата

QIODevice::write: ReadOnly device

Про WriteOnly соответственно
Выделить всёкод C++
1:

QIODevice::write: ReadOnly device

при обмене ключами.... другими словами эти флаги работают

Но я просто предполагал, что в случае записи, сохраняется последняя в устройстве строка, а при добавлении (Append) они уже конкатенируются... но видимо ошибся... просто не вижу разницы, что с write, что с append
Можно тролям написать узнать... хотя как правильно вопрос сформулировать.. поддержка стабильно отвечает по понедельникам

Использование QIODevice::Unbuffered, я так понимаю, тоже не вариант... тогда вообще данных не получу, надо сразу будет их читать по слоту....

эмм.. в методах read и write перед чтением идет проверка на корректность флагов вот:

Код


#define CHECK_WRITABLE(function, returnType) \
   do { \
       if ((d->openMode & WriteOnly) == 0) { \
           if (d->openMode == NotOpen) \
               return returnType; \
           qWarning("QIODevice::"#function": ReadOnly device"); \
           return returnType; \
       } \
   } while (0)

#define CHECK_READABLE(function, returnType) \
   do { \
       if ((d->openMode & ReadOnly) == 0) { \
           if (d->openMode == NotOpen) \
               return returnType; \
           qWarning("QIODevice::"#function": WriteOnly device"); \
           return returnType; \
       } \
   } while (0)

Автор: null56 3.8.2009, 09:58

Цитата(kuzulis @ 3.8.2009, 08:04)

2. Не конечного сообщения - а хотябы одного байта! (вроде)

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

Автор: kuzulis 3.8.2009, 10:50

null56,

хз.. тут уже нужно смотреть реализацию конкретного класса - наследника от QIODevice ..

Цитата

ну а попробуйте создать приложение №1 , которое будет , используя QTcpSocket методом write слать приложению №2 пакет с данными размером например 100 Мбайт и посмотрите как часто будет вызываться сигнал readyRead в приложении №2 после того как в приложении №2 мы читаем данные... кстати, интересный вопрос! smile

Добавлено через 4 минуты и 46 секунд
и опять же насчет емита сигнала:

если мы цепляемся на этот сигнал readyRead - то он с'эемиттится ОДИН раз при приходе данных (хотя бы 1 байта) ! Но . если мы после этого прочитаем пришедшие в буфер данные - то если придут опять данные - то сигнал с'емиттится еще раз..! Но если мы читать не будем их (данные) -то сигнал только 1 раз с'емиттится.. Я так понимаю это ИМХО

т.е все зависит от того, вызывали ли мы ф-ю чтения или нет

Автор: null56 3.8.2009, 11:07

Просто тогда возникает вопрос... как же тогда определить: когда придет конечное сообщение, а когда только его кусок....
накопить в устройстве сообщение, а потом разделить зная длину сообщения это можно... но я ведь даже длину не знаю
как же мне разделять команды, если я даже не знаю, когда закончится соощение7 самому придется какими - то символами отделять сообщение друг от друга?

Автор: SABROG 3.8.2009, 11:10

Придумывать протокол или взять протокол на основе xml, как Jabber. Ну или использовать http, ftp.

Автор: kuzulis 3.8.2009, 11:27

и вот мне интересно насчет принципа выдачи сигнала readyRead() . Я тут просмотрел исходники QAbstractSocket и там есть следующее (QT4.1) :

Код


bool QAbstractSocketPrivate::canReadNotification()
{
...
    // only emit readyRead() when not recursing.
    if (!emittedReadyRead) {
        emittedReadyRead = true;
        emit q->readyRead();
        emittedReadyRead = false;
    }
...
}

далее в

Код


bool QAbstractSocket::waitForReadyRead(int msecs)
{
    forever {
        bool readyToRead = false;
        bool readyToWrite = false;
        if (!d->socketEngine->waitForReadOrWrite(&readyToRead, &readyToWrite, true, !d->writeBuffer.isEmpty(),
                                               qt_timeout_value(msecs, stopWatch.elapsed()))) {
            d->socketError = d->socketEngine->error();
            setErrorString(d->socketEngine->errorString());
#if defined (QABSTRACTSOCKET_DEBUG)
            qDebug("QAbstractSocket::waitForReadyRead(%i) failed (%i, %s)",
                   msecs, d->socketError, errorString().toLatin1().constData());
#endif
            emit error(d->socketError);
            if (d->socketError != SocketTimeoutError)
                close();
            return false;
        }

        if (readyToRead) {
            if (d->canReadNotification())
                return true;
        }

        if (readyToWrite)
            d->canWriteNotification();

        if (state() != ConnectedState)
            return false;
    }
}

и если далее посмотреть реализацию waitForReadOrWrite - то видно , что в итоге используется ф-я select - а она ожидает события прихода хотя-бы одного байта в сокет!

Добавлено через 4 минуты и 10 секунд
НО мне непонятно, как срабатывает emit readyRead() если мы не вызываем метод waitForReadyRead - а просто коннектимся к сигналу readyRead() ???
ЗЫ: или я где-то "туплю"

Добавлено через 6 минут и 45 секунд

Цитата

Придумывать протокол или взять протокол на основе xml, как Jabber. Ну или использовать http, ftp.

Да, SABROG прав! Обычно для этих целей используют механизмы запрос/ответ , запрос/подтверждение и т.п. и тогда никаких коллизий быть не должно! т.е обычно для этих целей используют различные протоколы обмена!

Автор: null56 3.8.2009, 11:57

SABROG,
kuzulis,
отлично, а то что - то я не подумал об этом моменте...
для таких целей вполне можно использовать потоковый xml парсер от qt
например передавать данные в таком формате

Код


<msg>
   <id>идентификатор сообщения</id>
   <type>тип: snd, rcv (то есть новые данные или подтверждение полученных)</type>
   <data>собственно данные</data>
</msg>

далее в readyReady или по таймеру можно использовать потоковый парсер, например QXmlSteraReader и последовательно добавлять туда данные и сохранять готовые сообщения, а в eventloop проверять этот объект на наличие сообщений

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

Автор: kuzulis 3.8.2009, 12:07

эй! тема не закрыта! теперь давайте мне помогайте! smile

Автор: null56 3.8.2009, 12:28

я не совсем понял, в чем, но если ты про это

Цитата

НО мне непонятно, как срабатывает emit readyRead() если мы не вызываем метод waitForReadyRead - а просто коннектимся к сигналу readyRead() ???
ЗЫ: или я где-то "туплю"

то тогда ситуация такая
у тебя есть два варианта проверки устройства QIODevice
1) блокирующий режим
2) режим без блокировки
в каждом потоке у тебя работает EventLoop, вызываемый функцией exec()
он осуществляет всю обработку информации и проверку наличия соединения сиглана readyRead() со слотом...
и если на каком - то шаге, когда eventloop проверяет как раз наличие новых данных в буфере, выясняется, что есть функция (slot), которую надо вызвать при появлении новых данных, то в этой функции вызывается, как раз твой слот(ы) про обработке результата
waitForReadyRead приостанавливает дальнейший ход работы потока и передает управление eventloop для проверки наличия новых данных и ТОЛЬКО их на определенный промежуток времени, который ты задаешь в параметрах, после чего возвращает управление следующей команде после вызовы waitForReadyRead
во... вроде все так, если ничего не напутал...
то есть другими словами, эти функции друг другу не нужны, но им обоим нужен запущенный exec

Добавлено через 2 минуты и 31 секунду
другими словами или ты даешь eventloop возможность тебя оповестить о новых данных или говоришь евентлуп проверять данные прямо сейчас и ни делать более ни фига...

Автор: kuzulis 3.8.2009, 13:26

Цитата

в каждом потоке у тебя работает EventLoop, вызываемый функцией exec()
он осуществляет всю обработку информации и проверку наличия соединения сиглана readyRead() со слотом...
и если на каком - то шаге, когда eventloop проверяет как раз наличие новых данных в буфере,

а как EventLoop проверит это? откуда он знает что нужно проверять именно наличие новых данных в буфере и емиттить сигнал? ведь для проверки наличия данных в буфере необходимо вызывать метод waitForReadyRead - и ЭТОТ метод уже семиттит сигнал readyRead!!!!!

или же цикл EventLoop - ищет во всех методах сигналы , потом проеряет - если сигнал приконнекчен к какому либо слоту - то цикл EventLoop запускает(перебирает) по очереди все методы, в которых есть emit signals (в общем виде)? так чтоли?

но если так - то каое время в msecs цикл подставляет в метод для ожидания появления данных ???

Автор: SABROG 3.8.2009, 14:28

Цитата(kuzulis @ 3.8.2009, 13:26

)

но если так - то каое время в msecs цикл подставляет в метод для ожидания появления данных ???

30 секунд для waitForReadyRead () и бесконечное, если используется QEventLoop или просто основной цикл событий.

Цитата(kuzulis @ 3.8.2009, 13:26

)

Если рассматривать сетевое взаимодействие в Windows, то здесь ОС привязывает свои события (WM_MESSAGES) к окну. Поэтому, когда с сокетом происходит какая-то активность об этом генерится сообщение, которое передается окну. QEventLoop ловит это сообщение и передает объектам, которые могут его обработать. Возможно это QIODevice, возможно какой-то внутренний класс. Но уже этот объект на основе настроек эмитит сигнал readyRead (или любой другой). Поэтому, если цикла событий не существует или он блокирован какой-то долго выполняющейся функцией, то сообщение ставится в очередь и сигнал придет только тогда, когда управление вернется в цикл событий или пока он не будет запущен насильно.

Автор: kuzulis 3.8.2009, 14:36

Цитата

30 секунд для waitForReadyRead () и бесконечное, если используется QEventLoop или просто основной цикл событий.

т.е если я создам свой класс наследник QObject, определю в нем свои сигналы, методы (которые их испускают) и приконнекчу слоты к этим сигналам, то - автоматически цикл событий будет проверять (выполнять) мои методы которые испускают сигналы ?

Автор: SABROG 3.8.2009, 14:41

Цитата(kuzulis @ 3.8.2009, 14:36

)

Не будет. Нужно вызывать emit, чтобы слоты сработали.

Автор: kuzulis 3.8.2009, 14:42

Цитата

все-равно непонятно...
1. как QEventLoop передает именно пому кому нужно?
2. для отлова события от сокета (рассмотрим виндовс) НЕОБХОДИМО выполнить функцию select! иначе никак не отловим это! неужто QEventLoop - ловит прям каждое событие происходящее в системе?

Добавлено через 1 минуту и 1 секунду

Цитата

Не будет. Нужно вызывать emit, чтобы слоты сработали.

а кто тогда вызывает readyRead а ? smile

Автор: null56 3.8.2009, 15:07

Цитата(kuzulis @ 3.8.2009, 14:42)

а кто тогда вызывает readyRead а ? smile

никто, если он ни с чем не связан

Добавлено @ 15:09
суть в том, что связь connect, создает некоторый массив функций, которые нужно будет вызвать, а emit, указывает на небоходимость в данной точке вызова всех функций связанных с ним

Автор: kuzulis 3.8.2009, 15:15

Цитата

а кто тогда вызывает readyRead а ? smile

никто, если он ни с чем не связан

Добавлено @ 15:09
суть в том, что связь connect, создает некоторый массив функций, которые нужно будет вызвать, а emit, указывает на небоходимость в данной точке вызова всех функций связанных с ним

Это сообщение отредактировал(а) null56 - 3.8.2009, 15:11

так вот на примере с QAbstractSocket - если я делаю connect к readyRead - то тогда какие функции вызовутся для выдачи сигнала readyRead ? smile

Добавлено через 58 секунд
т.е какая ф-я семиттит этот сигнал?

Автор: null56 3.8.2009, 15:21

наверное эта

Код


d->canReadNotification()

Автор: kuzulis 3.8.2009, 15:38

Цитата

наверное эта
Выделить всёкод C++
1:

d->canReadNotification()

1. но для этого должна быть вызвана ф-я waitForReadyRead(msecs)!!!
2. кто вызовет ее?
3. какое значение будет у msecs ?

Автор: SABROG 3.8.2009, 16:38

Цитата(kuzulis @ 3.8.2009, 15:38

)

какое значение будет у msecs

Там не будет никакого значения, зачем оно нужно, если клиент может потенциально держать связь с сервером бесконечное время и не общаться? Например, если подключиться к MySQL серверу, то через часов 8 без активности сервак отключит клиента. Т.е. все это время сигнала readyRead() не будет. Я не думаю, что QAbstractSocket использует waitForReadyRead.

Автор: kuzulis 4.8.2009, 07:36

Цитата

Я не думаю, что QAbstractSocket использует waitForReadyRead.

а каким тогда образом емиттится сигнал readyRead? кто/что его емиттит ?