QUdpSocket requires delays between writes
-
Going back to your comment:
"ARP queues only one outbound IP datagram for a specified destination address while that IP address is being resolved to a media access control address. If a User Datagram Protocol (UDP)-based application sends multiple IP datagrams to a single destination address without any pauses between them, some of the datagrams may be dropped if there is no ARP cache entry already present. An application can compensate for this by calling the iphlpapi.dll routine SendArp() to establish an ARP cache entry, before sending the stream of packets."
I did the following:
#include <QCoreApplication> #include <QUdpSocket> #include <QTextStream> #include <QThread> int main(int argc, char *argv[]) { QCoreApplication app(argc, argv); QTextStream cout(stdout); QUdpSocket* myUdpSocket = new QUdpSocket; myUdpSocket->connectToHost("127.0.0.1", 50000); cout << myUdpSocket->write("msg 1\n") << Qt::endl; QThread::currentThread()->sleep(1); for(unsigned u = 0; u < 100; u++) cout << myUdpSocket->write("another\n") << Qt::endl; QThread::currentThread()->sleep(5); return 0; }As long as I have a delay after the first write, I get all 100 of the following at full speed. So ... something in the IP stack needs to get established. That first write seems to do it although it takes some time. I am wondering if since we are on 127.0.0.1 the ARP never goes out but the net result is the ARP cache gets created and then off we go.
Anyway, thank you very much for your time and expertise. I don't have a Linux box handy at the moment but I am curious if I get similar results. If I get a chance, I will try it and post the results here just for the record.
-
Going back to your comment:
"ARP queues only one outbound IP datagram for a specified destination address while that IP address is being resolved to a media access control address. If a User Datagram Protocol (UDP)-based application sends multiple IP datagrams to a single destination address without any pauses between them, some of the datagrams may be dropped if there is no ARP cache entry already present. An application can compensate for this by calling the iphlpapi.dll routine SendArp() to establish an ARP cache entry, before sending the stream of packets."
I did the following:
#include <QCoreApplication> #include <QUdpSocket> #include <QTextStream> #include <QThread> int main(int argc, char *argv[]) { QCoreApplication app(argc, argv); QTextStream cout(stdout); QUdpSocket* myUdpSocket = new QUdpSocket; myUdpSocket->connectToHost("127.0.0.1", 50000); cout << myUdpSocket->write("msg 1\n") << Qt::endl; QThread::currentThread()->sleep(1); for(unsigned u = 0; u < 100; u++) cout << myUdpSocket->write("another\n") << Qt::endl; QThread::currentThread()->sleep(5); return 0; }As long as I have a delay after the first write, I get all 100 of the following at full speed. So ... something in the IP stack needs to get established. That first write seems to do it although it takes some time. I am wondering if since we are on 127.0.0.1 the ARP never goes out but the net result is the ARP cache gets created and then off we go.
Anyway, thank you very much for your time and expertise. I don't have a Linux box handy at the moment but I am curious if I get similar results. If I get a chance, I will try it and post the results here just for the record.
@Mwvse said in QUdpSocket requires delays between writes:
As long as I have a delay after the first write, I get all 100 of the following at full speed. So ... something in the IP stack needs to get established. That first write seems to do it although it takes some time. I am wondering if since we are on 127.0.0.1 the ARP never goes out but the net result is the ARP cache gets created and then off we go.
Yes, this would seem to support that hypothesis indeed, but I didn't see a TCP broadcast in wireshark. In any case something very windows specific may be going on (which has nothing to do with Qt apparently). On the other hand if this turns out to be the case, I think Qt can do better to wait for the ARP cache to be built before sending the following datagrams.
If I get a chance, I will try it and post the results here just for the record.
This would be much appreciated.
