Broadcasting QVector data

akshaybabloo

I am trying to send a QVector data over UDP and I am using the example Broadcast sender and Broadcast receiver.

In the sender example, I edited broadcastDatagram() to convert a QVector<double> to QByteArray using QDataStream and the code looks like:

sender.cpp

void Sender::broadcastDatagram()
{
    QVector<double> vector;
    for (int i =0; i<=23 ;i++ ) {
        vector.append(-2.5);
    }

    qInfo() << vector;

    QByteArray line;
    QDataStream stream(&line, QIODevice::WriteOnly);
    stream << vector;

    statusLabel->setText(tr("Now broadcasting datagram %1").arg(messageNo));
//! [1]
    QByteArray datagram = line;
    udpSocket->writeDatagram(datagram, QHostAddress::Broadcast, 45454);
//! [1]
    ++messageNo;
}

In the receiver example, I edited processPendingDatagrams() to convert the data received back into QVector<double> via QDataStream.

reciever.cpp

void Receiver::processPendingDatagrams()
{
    QByteArray datagram;
//! [2]
    while (udpSocket->hasPendingDatagrams()) {
        datagram.resize(int(udpSocket->pendingDatagramSize()));
        udpSocket->readDatagram(datagram.data(), datagram.size());
        statusLabel->setText(tr("Received datagram: \"%1\"")
                             .arg(datagram.constData()));

        QVector<double> data;
        QDataStream stream(datagram.constData());
        stream >> data;
        qInfo() << datagram.data();
        qInfo() << data.size();
        qInfo() << data;
    }
//! [2]
}

The problem is that the data is data.size() is 0 buy datagram.size() is 196. The contents data and datagram.constData is empty.

I am not sure what's happening here, how should I recieve the bytearry sent?

Christian Ehrlicher

@akshaybabloo said in Broadcasting QVector data:

QDataStream stream(datagram.constData());

You should pass the QByteArray here, not a pointer to const char* - wonder why this compiles at all.

akshaybabloo

@Christian-Ehrlicher No idea. Thank you for your help.

Kent-Dorfman

Also understand that by using the Qt serialization QDataStream you make Qt a requirement on the receiver. It's generally considered bad form to transport IEEE floating point numbers across any heterogenous network, but instead to translate them to either readable text (resulting in bandwidth bloat), or use a scaled integer approach (requiring a proper analysis of the required data value precision). Many will disagree with my comment, but I content that disagreement is more a result of laziness, as opposed to a wish for interoperability.

JKSH

@Kent-Dorfman said in Broadcasting QVector data:

It's generally considered bad form to transport IEEE floating point numbers across any heterogenous network

Why, and by whom?

We already have well-defined, standardized binary protocols like CBOR which can be used to transmit IEEE 754 values unambiguously, losslessly, and efficiently.

Kent-Dorfman

We already have well-defined, standardized binary protocols like CBOR which can be used to transmit IEEE 754 values unambiguously, losslessly, and efficiently.

A protocol that is based on JSON is anything but efficient. You have introduced the requirement of a grammar parser.

In my world (embedded and control systems) things need to be liteweight, interoperable, and unambiguous. Scaled integer approaches are almost always superior, unless bandwidth bloat of text representation is tolerable.

As for CBOR...it's an RFC, not an industry standard such as IEEE or ISO standards...so is really only applicable to IP.

In deterministic monitoring and control venues (especially dealing with multiple vendors) the scaled integer approach is about as efficient and unambiguous as it gets as long as endian orders are respected.

JKSH

@Kent-Dorfman said in Broadcasting QVector data:

We already have well-defined, standardized binary protocols like CBOR which can be used to transmit IEEE 754 values unambiguously, losslessly, and efficiently.

A protocol that is based on JSON is anything but efficient. You have introduced the requirement of a grammar parser.

Hardly. CBOR's structure is fixed header + payload.

No grammar parsing required, unlike JSON.

In my world (embedded and control systems) things need to be liteweight, interoperable, and unambiguous. Scaled integer approaches are almost always superior, unless bandwidth bloat of text representation is tolerable.

Please allow for answers that cater for people outside your world.

IEEE floating point numbers require no scaling on the receiver and involves no bandwidth bloat.

As for CBOR...it's an RFC, not an industry standard such as IEEE or ISO standards...so is really only applicable to IP.

That matters because...?