When I send using QIODevice::write sometimes (like 10% like so) my server (made in golang) does not receive the packet.
I use wireshark to wire tap the TCP communication. Here are my observations:
To write I use the following code:
QByteArray bmsg = UldHelper::formatMessage(msg); qint64 bWritten = s->write(bmsg); qDebug()<<"Bytes Written:"<<bWritten; s->waitForBytesWritten(bmsg.size());
And most of the time the info is read by the server. And sometimes it does not.
When I check the packets I got the following for a successful tx:
563 22.425583 192.168.1.3 192.168.1.5 TCP 120 52758→8989 [PSH, ACK] Seq=1 Ack=1 Win=131744 Len=54 TSval=176586223 TSecr=748716139 569 22.431333 192.168.1.5 192.168.1.3 TCP 120 8989→52758 [PSH, ACK] Seq=1 Ack=56 Win=131712 Len=54 TSval=748716144 TSecr=176586224
And those not many times when the tx fails:
4736 235.902538 192.168.1.3 192.168.1.5 TCP 120 52788→8989 [PSH, ACK] Seq=1 Ack=1 Win=131744 Len=54 TSval=176798384 TSecr=748928895
See? When successful. the server confirms the info arrived, it's like a two round trip (SrcPort:52758 ---> DstPort:8989), going and coming (8989->52758)
But when communications fails it only goes but never turn back (52788 --> 8989). No the other way around. This is confusing because I have tried with a non Qt implementation and it did the job. I guess if the QTcpSocket implementation has a bug or something......
Note that I'm not using signals or slots whatsoever... only waiting for bytes to write, which to me seems blockysome... not cool.
What do you think. Thank you!.
Hi just guessing here, but maybe Qt is too fast or efficient so that golang's input buffers overflow?
If you try inserting a slight delay after the wait, say:
... s->waitForBytesWritten(bmsg.size()); QThread::msleep(100);
will that change the failure rate?
@hskoglund Thank you. No I do not think that being the case... I trigger the communication by clinking on a QtQuick Rectangle! ;)
On a second thought I reviewed the golang server code and it is a echo Server, that's why successful packets come and go. It's like the problem was in the server, rather than in the client.
So I guess you could be right.
Gonna give it a try....