TCP vs UDP
-
Re: Why QTcpSocket::waitForBytesWritten returns immediately
Hello, as described in the referenced tread i can not be sure that my TCP packet is arrived. I must give me an acknowledge from the receiver.
Why i use then TCP and not UDP ?
Sorry for these "stupid?" question... -
Re: Why QTcpSocket::waitForBytesWritten returns immediately
Hello, as described in the referenced tread i can not be sure that my TCP packet is arrived. I must give me an acknowledge from the receiver.
Why i use then TCP and not UDP ?
Sorry for these "stupid?" question...@sirAnton said in TCP vs UDP:
Hello, as described in the referenced tread i can not be sure that my TCP packet is arrived.
The Transmission Control Protocol (TCP) detects packet loss and performs retransmissions to ensure reliable messagingThe idea behind tcp is no packet loss. For UDP however, there is absolutely no guarantee that your packet arrived
Be aware of the Qt Code of Conduct, when posting : https://forum.qt.io/topic/113070/qt-code-of-conduct
Q: What's that?
A: It's blue light.
Q: What does it do?
A: It turns blue. -
@sirAnton said in TCP vs UDP:
Hello, as described in the referenced tread i can not be sure that my TCP packet is arrived.
The Transmission Control Protocol (TCP) detects packet loss and performs retransmissions to ensure reliable messagingThe idea behind tcp is no packet loss. For UDP however, there is absolutely no guarantee that your packet arrived
@J-Hilk
Question: As per the referenced topic and @aha_1980's answer thereHow can i know when data sent fully?
IMHO you cannot.
Please note that in a distributed network it does not mean much when a TCP packet is sent out, it can have a long way until it's destination. It can even be re-send if the sender does not get an ACK from the receiver.
What you can do, is to give an acknowlegde from the receiver side once it received the data and evaluate that on the sender side.If TCP protocol knows to re-send if it does not get TCP-level ACK from receiver, why do "you" have to write code at receiver side to send back message for completion? Why can't/doesn't TCP let you know when it does receive that ACK, so that you'd know it didn't need retry and had arrived?
-
@J-Hilk
Question: As per the referenced topic and @aha_1980's answer thereHow can i know when data sent fully?
IMHO you cannot.
Please note that in a distributed network it does not mean much when a TCP packet is sent out, it can have a long way until it's destination. It can even be re-send if the sender does not get an ACK from the receiver.
What you can do, is to give an acknowlegde from the receiver side once it received the data and evaluate that on the sender side.If TCP protocol knows to re-send if it does not get TCP-level ACK from receiver, why do "you" have to write code at receiver side to send back message for completion? Why can't/doesn't TCP let you know when it does receive that ACK, so that you'd know it didn't need retry and had arrived?
@JonB I'm by no means on expert on this, but I would assume the answer is in the API / Standard and that it's not defined there.
The OS manages the data transaction and resends the packet if necessary.
Therefore the acknowledgment is not passed along to the application level.
š¤·āāļø
Be aware of the Qt Code of Conduct, when posting : https://forum.qt.io/topic/113070/qt-code-of-conduct
Q: What's that?
A: It's blue light.
Q: What does it do?
A: It turns blue. -
@JonB I'm by no means on expert on this, but I would assume the answer is in the API / Standard and that it's not defined there.
The OS manages the data transaction and resends the packet if necessary.
Therefore the acknowledgment is not passed along to the application level.
š¤·āāļø -
@J-Hilk said in TCP vs UDP:
Therefore the acknowledgment is not passed along to the application level.
Yeah, but I want it to be! Then we could keep the OP happy :)
@JonB said in TCP vs UDP:
Yeah, but I want it to be! Then we could keep the OP happy :)
well, how good are you at driver coding ?
-
I think the side question about TCP level ACK and transaction ACK goes to the function of TCP transactions. Since TCP is itself a stream/session protocol there is no implicit understanding of an application packet. That is left up to the application layer to define and implement a transaction protocol over top of TCP. If the OP simply wants guaranteed discrete messages then sometimes UDP with some application level retries is better than defining an application layer TCP protocol that frames the data as expected, IMHO.
