The only difference between TCP and UDP in modern TCP implementations is that Application now fully controls the UDP port instead of OS implementing for you one logical stream. You'll need to implement that logical sequence of bytes yourself in application in case of UDP, but you can tweak now logic for managing how data is read from each datagram, add "application ports" along with OS'es UDP ports, and also encrypt all of that information. Considering that TCP header always at least 20 bytes, and UDP is only 8, there is plenty of room for creativity.
what about lost segement? Quick will request to resend it to client again? or that stream will be lost permanently? You did not share much details on it. ?
@hnasr, you are the guy I would love to have as my boss. I love the topics you touch upon and your interest and passion for under-the-hood engineering details. I always wanted someone who can explain these things to me but never found one until I found your channel.
But, since there is no resend packet in UDP, how does client know that lost and send that packet again? timeout? or quic somehow manages and tells that to the client?
UDP has two options here - either you rely on an Upper Layer Protocol to care of this for you (e.g., QUIC, but there are many others) OR you simply don’t care that’s it’s lost because the app may be time sensitive (e.g., VoIP - Voice over IP - where it doesn’t make sense to wait around and reassemble retransmitted packets. Most of the time it’s not that noticeable, but if you do happen to lose a bunch, then a Very Upper Layer Protocol, I.e., the human being on the other end, simply asks someone to repeat what they said)
@@nathansherrard4111 you're never just "don't care". Application will see either next packet got out of order and decides what to do with that information, or it essentially times out either on UDP port if no packets got to the host or you're more preciselly can timeout on that one logical stream that was expecting it's packet to get to one UDP port.
This is such a good channel
Hussein 2:37 Don't pay attention to the numbers
Also Hussein 2:55 Just look at the numbers
😄
The only difference between TCP and UDP in modern TCP implementations is that Application now fully controls the UDP port instead of OS implementing for you one logical stream. You'll need to implement that logical sequence of bytes yourself in application in case of UDP, but you can tweak now logic for managing how data is read from each datagram, add "application ports" along with OS'es UDP ports, and also encrypt all of that information. Considering that TCP header always at least 20 bytes, and UDP is only 8, there is plenty of room for creativity.
... Http3 enters
Brilliant, brilliant Hussein! As-salamu alaykum!
Quic is like tcp but work on segments group
what about lost segement? Quick will request to resend it to client again? or that stream will be lost permanently? You did not share much details on it. ?
@hnasr, you are the guy I would love to have as my boss. I love the topics you touch upon and your interest and passion for under-the-hood engineering details. I always wanted someone who can explain these things to me but never found one until I found your channel.
But, since there is no resend packet in UDP, how does client know that lost and send that packet again? timeout? or quic somehow manages and tells that to the client?
UDP has two options here - either you rely on an Upper Layer Protocol to care of this for you (e.g., QUIC, but there are many others) OR you simply don’t care that’s it’s lost because the app may be time sensitive (e.g., VoIP - Voice over IP - where it doesn’t make sense to wait around and reassemble retransmitted packets. Most of the time it’s not that noticeable, but if you do happen to lose a bunch, then a Very Upper Layer Protocol, I.e., the human being on the other end, simply asks someone to repeat what they said)
UDP and TCP each have their purpose and use cases, and as long as you use the right tool for the right job you are OK.
@@nathansherrard4111 got it. Thank you very much!
@@nathansherrard4111 you're never just "don't care". Application will see either next packet got out of order and decides what to do with that information, or it essentially times out either on UDP port if no packets got to the host or you're more preciselly can timeout on that one logical stream that was expecting it's packet to get to one UDP port.
Thank you
Genius ❤
نفع الله بك
❤❤❤