QTcpSocket emitting readyRead() sync

Hello!

I have an debug application with a QTcpSocket client that should receive something like 6 packages by second - that's precise. So I would imagine that the readyRead() signal would be emmited around 6 times per second, each time related to one of the packages that were send. But what happens is very different:

rather than emiting 6 singals per second well divided in time, usually 2 to 3 readyRead signals are emmited very quickly one after the other with the data received:

Code:

---

"0" "56:10:484" 8192 Data received (readyRead) 
"0" "56:10:485" 323 Data received (readyRead) 
"0" "56:11:358" 8192 Data received (readyRead) 
"0" "56:11:358" 323 Data received (readyRead) 
"0" "56:12:340" 3472 Data received (readyRead) 
"0" "56:12:340" 5043 Data received (readyRead) 
"0" "56:13:542" 3472 Data received (readyRead) 
"0" "56:13:542" 5043 Data received (readyRead) 
"0" "56:14:306" 8192 Data received (readyRead) 
"0" "56:14:306" 323 Data received (readyRead) 
"0" "56:15:397" 3472 Data received (readyRead) 
"0" "56:15:398" 5043 Data received (readyRead)

---

(the number before "Data received" is get by bytesAvailable())

And that happens, as you may see, like once per second. Is there a way to change this behaviour making readyRead() be emitted in a way closer to what was expected? It's like if there was a thread inside QIODevice that looks for new data once per second...


Thanks,

Momergil

Obs.: maybe has something to do with [http://www.qtcentre.org/threads/1502...d(QTCPSOCKET)]

Quote:

---

Is there a way to change this behaviour making readyRead() be emitted in a way closer to what was expected?

---

Qt is issuing readyRead() exactly as expected and documented. readRead() is signalled when new data has arrived. You need to understand that there is no relationship between the size and timing of data blocks written by the sender and the size and timing of received chunks of data (driven by network block, hardware and operating system buffers sizes). TCP guarantees that all data written will arrive intact and in the correct order; it does this using a system of sequence numbers, checksums, acknowledgement messages, and retransmissions. TCP makes no guarantees about timing (it cannot control network conditions) or that a chunk written at one end is received as a single chunk at the other (this is, BTW, unlikely except for small infrequent chunks).

If you want to emit a signal only when some complete application layer protocol data unit (PDU) is received then you need to buffer the incoming data, inspect the data for a complete PDU, and emit the signal you want.

Depending on the application, UDP may be a better choice.