Well, I was just trying to create an small example to send to the list and it didn’t show the problem.
I think I have just found the problem. The B program I mentioned has Bonjour browsing service implemented by a really old Qt project BonjourServiceRegister. I have commented it out and the problem disappeared. I don’t know why, but it seems that Bonjour Service Register is provoking this stall. Can anyone guess why? Does anyone know any more recent Qt wrapper for dns_sd? Regards, Nuno Santos Founder / CEO / CTO www.imaginando.pt +351 91 621 69 62 > On 24 Apr 2015, at 13:11, Klank, Michael <michael.kl...@amk-antriebe.de> > wrote: > > We had the same problem. > setSocketOption(QAbstractSocket::LowDelayOption, 1); solved the problem > > Von: interest-bounces+michael.klank=amk-antriebe...@qt-project.org > [mailto:interest-bounces+michael.klank=amk-antriebe...@qt-project.org] Im > Auftrag von Nuno Santos > Gesendet: Freitag, 24. April 2015 13:24 > An: Andre Barth > Cc: Interests Qt > Betreff: Re: [Interest] Q(Tcp/Udp)Socket stall > > This happens, even with Wifi turned off. > > Nuno > > On 24 Apr 2015, at 12:18, Andre Barth <andre.ba...@autodesk.com> wrote: > > Are you on Wifi (only)? > > We did run into similar issues on 5.3.2 (but I don't know whether this is > related to your problem, too): The reason for our problem was/is, that ... > > "...it looks as if Qt’s “Network Configuration Manager” was polling the Wifi > engine every 10 seconds for available networks. > > This in turn will call Windows’ WlanScan function which “… requests a scan > for available networks on the indicated interface…” > (see qnativewifiengine::requestUpdate, line 517) " > > Could be right, could be wrong - but this is what I've seen. > > Thanks, > Andre > > -----Original Message----- > From: interest-bounces+andre.barth=autodesk....@qt-project.org > [mailto:interest-bounces+andre.barth=autodesk....@qt-project.org] On Behalf > Of Nuno Santos > Sent: Friday, April 24, 2015 1:01 PM > To: Interests Qt > Subject: [Interest] Q(Tcp/Udp)Socket stall > > Hi, > > I have passed the last 48 hours trying to understand a problem I was having > with sockets. I was driving crazy but I think I finally reached a conclusion. > Let me summarize: > > - Program A that sends data via sockets to localhost > - Program B, built in Qt, receives data via QUdpSocket (I have also tried > with QTcpSocket and the problem is the same). > > Program A sends constant size messages (76 bytes) each 60 ms. > Program B receives the message and prints the latency between the current > message and the last message. > > The result is the following: > > latency 19 > latency 60 > latency 60 > latency 60 > latency 51 > latency 59 > latency 80 > latency 61 > latency 60 > latency 58 > latency 50 > latency 60 > latency 59 > latency 538 > latency 0 > latency 43 > latency 58 > latency 62 > latency 79 > latency 50 > latency 50 > latency 61 > latency 61 > latency 58 > latency 60 > latency 80 > latency 31 > latency 59 > latency 1946 > latency 0 > latency 54 > latency 61 > latency 49 > latency 59 > latency 52 > latency 60 > latency 58 > latency 60 > latency 60 > latency 60 > latency 60 > latency 60 > latency 51 > latency 533 > latency 0 > latency 16 > latency 60 > latency 60 > latency 60 > latency 50 > latency 60 > latency 61 > latency 60 > latency 59 > > From time to time, in a pretty much regular way, the message receiving stalls > and the latency is printed as being around 500ms/1000ms/2000ms. > > Even the interval between stalls is pretty much regular, around 14 packets. > Each packet is 76 bytes, which multiplied by 14 gives around 1024. > > I didn’t rest while I couldn’t who the fault was. So I did a C program that > receives data on a socket from the same source to ensure that there was no > stalls or latency. The result was NO STALLS. > > Then, I have done another program, this time built in Qt, to send data via > QUdpSocket to the program B. The result was: STALLS again! > > My conclusion is that somewhere in the underlying Qt socket handling, there > is a buffer, to be filled before readyRead is sent. > > Is anybody familiar with this problem and know how to work around it? Is this > a setting that can be tweaked? > > This doesn’t seem normal or acceptable. > > Thx, > > Regards, > > Nuno Santos > _______________________________________________ > Interest mailing list > Interest@qt-project.org > http://lists.qt-project.org/mailman/listinfo/interest > > > ________________________________ > > Persönlich haftende Gesellschafterin: AMK Verwaltungsgesellschaft mbH, > Kirchheim/Teck > Geschäftsführer: Dr. Thomas Lützenrath, Jochen Breßmer, Dr. Ulrich Viethen > Registergericht Stuttgart HRB 230208; HRA 230681 > > Die in dieser E-Mail enthaltenen Informationen sind vertraulich. Diese E-Mail > ist ausschließlich für den Adressaten bestimmt und jeglicher Zugriff durch > andere Personen ist nicht zulässig. Falls Sie nicht der beabsichtigte > Empfänger sind, ist jegliche Veröffentlichung, Vervielfältigung, Verteilung > und sonstige in diesem Zusammenhang stehende Handlung untersagt und unter > Umständen ungesetzlich. Falls Sie diese E-Mail irrtümlich erhalten haben, > leiten Sie sie bitte weiter an die folgende E-Mail-Adresse: > i...@amk-antriebe.de > > The information in this e-mail is confidential. It is intended solely for the > address and access to the e-mail by anyone else is unauthorised. If you are > not the intended recipient, any disclosure, copying, distribution or any > action taken or committed to be taken in reliance on it, is prohibited and > may be unlawful. If you have received this e-mail in error please forward to > this e-mail-address: i...@amk-antriebe.de >
_______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
