tntcoda
22nd May 2009, 21:54
Hi,
I'm wondering if someone could kindly help me with a high level design for how to download through a QTCPSocket, in order to obtain reliable downstream speeds in real time.
Its a custom protocol, but basically once I issue a request for some data, I need to keep downloading until I receive the terminating bytes <CR><LF>.<CR><LF>
Here is my current thinking:
- Request data download
- Record current timestamp
- Read X bytes through the socket
- Record new timestamp, compute time difference and work out speed for the transfer of X bytes, signal this out...
- Repeat until terminating bytes: <CR><LF>.<CR><LF> are detected.
Does this seem like a solid approach to the problem? If so, my question is how many bytes should I read per cycle (size of X)?
Baring in mind the transfer size could be a few bytes to many megabytes, what transfer cycle size is good for best performance, and also enough to calculate reliable, real-time download speeds?
I guess also I would need to record the last cycles data in case half of the terminating bytes came through at the end of the last cycle? :confused:
Many thanks for any help,
Jack
I'm wondering if someone could kindly help me with a high level design for how to download through a QTCPSocket, in order to obtain reliable downstream speeds in real time.
Its a custom protocol, but basically once I issue a request for some data, I need to keep downloading until I receive the terminating bytes <CR><LF>.<CR><LF>
Here is my current thinking:
- Request data download
- Record current timestamp
- Read X bytes through the socket
- Record new timestamp, compute time difference and work out speed for the transfer of X bytes, signal this out...
- Repeat until terminating bytes: <CR><LF>.<CR><LF> are detected.
Does this seem like a solid approach to the problem? If so, my question is how many bytes should I read per cycle (size of X)?
Baring in mind the transfer size could be a few bytes to many megabytes, what transfer cycle size is good for best performance, and also enough to calculate reliable, real-time download speeds?
I guess also I would need to record the last cycles data in case half of the terminating bytes came through at the end of the last cycle? :confused:
Many thanks for any help,
Jack