QUdpSocket, speeding up...
-
I have written a classed derived from QUdpSocket, I connect to the signal QUdpSocket::readyRead, this is connected to a slot in my derived class SckServer::readUDP.
I'm trying to optimise a file transfer and want to explore every option, is there anything I can do to speed up the transfer, any options in the class that would help?
-
Hi,
Not in the class no. At some point it's going to depend on your hardware, OS network stack, its settings and drivers.
Note that transferring files with UDP is risky since there's no guarantee that all data will arrive.
Interested in AI ? www.idiap.ch
Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct -
Hi,
Not in the class no. At some point it's going to depend on your hardware, OS network stack, its settings and drivers.
Note that transferring files with UDP is risky since there's no guarantee that all data will arrive.
@SGaist , I chose UDP because I can transfer more data in larger packets to multiple clients, the classes I've written work well and the clients request each packet, every packet is numbered from the file. If a client doesn't receive the correct packet it will re-request and if it receives a packet out of sequence it will also re-request the correct packet. All data is CRC'd and checked by the receiving clients.
Kind Regards,
Sy -
@SGaist , I chose UDP because I can transfer more data in larger packets to multiple clients, the classes I've written work well and the clients request each packet, every packet is numbered from the file. If a client doesn't receive the correct packet it will re-request and if it receives a packet out of sequence it will also re-request the correct packet. All data is CRC'd and checked by the receiving clients.
-
@SPlatten
OOI, and not meaning to derail the question, but by the time you do all this necessary correction for packets aren't you back at similar timings to if you did it safely by TCP? -
@JonB , no, nowhere near, a TCP packet is limited in size to around 1.5K where as UDP can transfer up to 64K in a single packet. Also UDP is connectionless, so multiple clients can receive broadcasted packets.
-
@SPlatten Then I don't know why the whole Internet doesn't do its file transfers that way. But we can leave it at that :)
@JonB , true, however these files are very large some GB...and the requirement is very tight on transfer speeds and time, the specification is a bit of a problem because it was written by plucking figures out of the air and not based on anything in reality. I didn't write it, it was all written before I started work on the project.
-
Using udp to transfer huge chunks of files is somewhat stupid since you have to write your own tcp handling on top of it again which is for sure much way slower than using tcp directly. So it's only an option when tcp is not available.
-
@SGaist , I chose UDP because I can transfer more data in larger packets to multiple clients, the classes I've written work well and the clients request each packet, every packet is numbered from the file. If a client doesn't receive the correct packet it will re-request and if it receives a packet out of sequence it will also re-request the correct packet. All data is CRC'd and checked by the receiving clients.
@SPlatten said in QUdpSocket, speeding up...:
I chose UDP because I can transfer more data in larger packets to multiple clients
Is this sending to a broadcast or multicast address?
a TCP packet is limited in size to around 1.5K where as UDP can transfer up to 64K in a single packet
Are you intimately familiar with the TCP/IP implementations the application is using? If not, I don't believe that these numbers are likely to be accurate. 1.5K, eg 1500 octets is a common MTU, of which a single TCP packout could use 1460 octets as data. UDP/IP packets are going to be similarly fragmented, or even truncated.
Also UDP is connectionless, so multiple clients can receive broadcasted packets.
I guess this confirms my initial question. Broadcast/multicast might result in better performance. The problem space sounds a little like multicast video streaming. Looking into RTP/RTSP/RTCP might be worthwhile. I haven't seen a QAbstractSocket implementation.
