2015-06-16 5 views
0

Я довольно новичок в Qt. Я унаследовал проект QtCreator, построенный с использованием Qt 4.8.1, и попытался перестроить его с помощью Qt 5.4.2, чтобы добавить функциональность. Я успешно восстановил проект под окнами 7 (Mingw) и linux с Qt5.Вопрос QT4 - QT5 - UDP

Все работает хорошо, пока я не запустил подключенные устройства и не получил поток UDP - где старый проект (на том же компьютере, что и новый код) будет с радостью получать и хранить данные, новый проект задыхается очень быстро при некотором произвольном количестве данные и не будут принимать новые данные.

EDIT размер пакета - все входящие небольшие пакеты принимаются. Обычно есть некоторые контрольные и вспомогательные пакеты небольшого размера (~ 100 байт), которые работают нормально. Проблема возникает, когда начинается сбор данных; полезная нагрузка входящего пакета данных составляет 1441 байт, и это быстро задохнется.

Неужели кто-нибудь испытывает эту проблему, переносясь на Qt5? Есть ли очевидная причина для произвольной остановки? Я добавил счетчик отладки в методе processDatagrams, чтобы показать текущее количество обработанных дейтаграмм, и оно варьируется, но составляет около нескольких сотен до его завершения.

EDIT Я добавил счетчик цикла while и распечатал с помощью qDebug. Это, очевидно, замедлит работу, и данные будут получать примерно на 1/10 фактической скорости передачи данных, и это будет продолжаться бесконечно. Это может намекнуть на проблему.

void ReceiveSocket::readPendingDatagrams() 
{ 
    volatile int i = 0; 
    QByteArray * data; 
    while(udpReceiveSocket->hasPendingDatagrams()) { 
     qDebug()<<i; 
     i++; 
     data = new QByteArray; 
     data->resize(udpReceiveSocket->pendingDatagramSize()); 
     QHostAddress sender; 
     quint16 senderPort; 
     udpReceiveSocket->readDatagram(data->data(), 
       sdata->size(),&sender, &senderPort); 
     emit processDatagrams(data); 
    } 
} 

На данный момент, я собираюсь использовать библиотеки Qt4, пока у меня больше возможностей для отладки поведения с Qt5

+1

Вы никогда не инициализируете данные 'QByteArray *, но вы пытаетесь его использовать. Почему бы вам просто не объявить его как «данные QByteArray»? Также почему у вас есть два 'QByteArray'? – thuga

+0

Я отредактировал sdata out - typo – johnnymopo

+0

Есть ли причина, по которой 'data' является указателем? Вы даже удаляете его в любом месте? – thuga

ответ

0

Прежде всего, нет необходимости в new QByteArray

void ReceiveSocket::readPendingDatagrams() 
{ 
    while(udpReceiveSocket->hasPendingDatagrams()) { 
     int len = udpReceiveSocket->pendingDatagramSize(); 
     QByteArray data; 
     data->resize(len); 
     udpReceiveSocket->readDatagram(data.data()); 
     emit processDatagrams(data); 
    } 
} 

так это должен исправить возможную ошибку с data (не инициализирован) and sdata (whatever this is). I discarded the variables отправитель and senderPort`, потому что в вашем коде они не были необходимы, и вы можете добавить их в случае необходимости позже

Обратите внимание, что датаграммы UDP имеют ограниченный размер. они будут разделены на определенную длину самим сокетом, когда она будет длиннее размера пакета. Я обычно использую пакеты с размером < 512, должен быть минимальной длиной по умолчанию пакетов UDP-данных маршрутизаторами и такими

+0

sdata был опечаткой - этот код работал в реализации Qt4, но не в Qt5.Меня беспокоит размер пакета. У меня нет контроля над размером входящего пакета (проблема с размером полезной нагрузки UDP равна 1441, другие меньшие датаграммы поставляются). Сеть состоит из двух устройств, коммутатора и компьютера. Я могу проверить, работают ли устройства, и все пакеты доставляются с помощью Wireshark. Я отредактирую свой вопрос. – johnnymopo

0

Эта ошибка появилась в Qt 5.4.2. Перейдите на 5.4.1 или включите код обработки событий в цикле, как это было предложено Зайборгом.

+0

Egnite - у вас есть номер отчета об ошибке Qt, на который я могу ссылаться? – johnnymopo

+0

Я собирался добавить отчет об ошибке сегодня, но быстрый поиск показал, что уже существует, даже связанное исправление, см. QTBUG-43857. – egnite

Смежные вопросы