Unsolved Help writing non blocking TCP code
-
Correct. However this tutorial also provides a threaded example where the UI thread is kept disentangled from the socket operations.
-
@kshegunov
Hello, Sorry, I missed the 2nd part, since they was not much visible code, I did not spot it...Anyhow, what you are saying is that, in my case, I have to go threaded to solve my issues? There is no way to change the code in the onByteWrittenSlot to make it work, something like:
// This is connected to the socked byteWritten signal to do the rest of the sending ansychrnously void onByteWrittenSlot(int NbBytes) { if (sendingPos>=dataToSend.count()) // Done sending? dataToSend.clear; // clear the buffer else { int nb= socket.getNumberOfBytesICanWriteWithoutBlocking(); sendingPos+= socket.write(dataToSend.data(), min(dataToSend.count()-sendinPos, nb)); // send the next block } }
Cyrille
-
@Cyrille-de-Brebisson said in Help writing non blocking TCP code:
Anyhow, what you are saying is that, in my case, I have to go threaded to solve my issues?
You don't "have to", strictly, but if you're working with rather big datasets it's going to be beneficial, so you don't get the network latency to show into the GUI thread.
There is no way to change the code in the onByteWrittenSlot to make it work, something like
However you change it it's still going to require time to flush the buffers from the socket layer to the actual network, and from Qt to the socket layer. If the data is large-ish, it can be noticeable, so that's when you'd opt for threads - when you can't tolerate the latency. In most cases you can work with the GUI thread fine, though, I'm not saying you always have to do the threading.
(Note that Qt already buffers the data for you, so most of what you do with that second buffer isn't necessary)
-
Hello,
@kshegunov said in Help writing non blocking TCP code:
Note that Qt already buffers the data for you, so most of what you do with that second buffer isn't necessary)
Does this mean that if I do a socket.write(QByteArray), regardless of the size of the byteArray, it will write the whole thing at once (ie: write will return the count of the QByteArray) as QT will buffer the array (this is assuming of course that they are no errors)?
When is onByteWrittenSlot called? Once the whole data that was sent to write is finally fully passed through to the native network layer? or would writing 10MB to a socket cause multiple signals?
If I reuse the above 10MB example.
If I have a 10MB ByteArray can I do a single socket.write(array) and will I get a single onByteWrittenSlot signal in return?Cyrille
-
@Cyrille-de-Brebisson said in Help writing non blocking TCP code:
When is onByteWrittenSlot called?
Is perfectly documented in the signal documentation:
This signal is emitted every time a payload of data has been written to the device's current write channel. The bytes argument is set to the number of bytes that were written in this payload.
-
Hello,
@Christian-Ehrlicher said in Help writing non blocking TCP code:
This signal is emitted every time a payload of data has been written to the device's current write channel. The bytes argument is set to the number of bytes that were written in this payload.
yep, I read that, what I do not know is if a "payload of data" is the equivalent of one write call or something else...
Cyrille
-
@Cyrille-de-Brebisson It's OS-dependent and should not matter at all. The important thing is you get a progress.
-
@Cyrille-de-Brebisson said in Help writing non blocking TCP code:
If I have a 10MB ByteArray can I do a single socket.write(array) and will I get a single onByteWrittenSlot signal in return?
No you may get multiple, as Christian wrote, it still shouldn't matter.
-
Hello,
What maters to me is that I would like, if possible, to not block the GUI...
At the moment, my socket.write calls seems to do so :-(
I would rather, if possible, avoid threads.
So, here is another formulation of the question.
Is there a way for me to know how many data can be "in the QT side of the pipe" so that I am not causing stalls in my write calls?Then, I can monitor the differential bettwen the "byte written" signal data and what I sent through write to "throttle" my writes and stay bellow this limit. Limit which might vary per OS/network channel of course.
Cyrille
-
@Cyrille-de-Brebisson said in Help writing non blocking TCP code:
At the moment, my socket.write calls seems to do so :-(
But not because of the write() call since this is done async as already explained. Please provide a minimal example to reproduce the issue you're seeing.