UDP Send Interval
-
Because i need to use UDP (that's it!) So... what i've done? I exactly realized that, what you told me. I check the correctness of the package, i check if the previous package is failing (and ask the other client for that package) and to "ii)" because that's why i have a sequential number in each data package. That isn't right, that the sending interval is irrelevant, because if i send data over the internet (behind two NAT) slowly, i get all data, but if i do this very fast, i have a high loss-rate, which i want to avoid. So i need to calculate the "correct" and stable data-sending rate.
softwarejaeger wrote:
So i need to calculate the "correct" and stable data-sending rate.
Not an easy thing to do, since it depends on other factors, such as traffic density on the network, network reliability etc. I think you may find that these are the sort of things that need to be recalculated on a regular basis for optimum performance. Which is why most people will just say "use TCP, that's what it is designed for". However if you are able to create a better performing protocol using UDP you may be on your way to fame and fortune.
Just say 'NO' to evaluated arguments for diadic functions! Ash
-
Well.. so for everyone, why i'm using UDP instead of TCP. First point: NAT (I need to make whole punching, because i need a P2P Connection) Second point: Latency (In a few cases, i doesn't need the whole "TCP" Features, i just want to send little messages) My protocol is doing exactly that and can all of kind like check for sequence, check for corrupcy and so on. But... i want the best performance and network bandwith load. So i need to calculate, how many packages i'm able to send, to not get a huge of requests back again.
Oh, ok, I think I understand now. You mean you still have to implement some congestion control mechanism, don't you? I have never done this, but there are several possible approaches. This article[^] might give you a point of start. You might want to have a look at SCTP protocol as well. It is not natively supported on Windows but there is a Windows driver here[^] which you could use.
-
Because i need to use UDP (that's it!) So... what i've done? I exactly realized that, what you told me. I check the correctness of the package, i check if the previous package is failing (and ask the other client for that package) and to "ii)" because that's why i have a sequential number in each data package. That isn't right, that the sending interval is irrelevant, because if i send data over the internet (behind two NAT) slowly, i get all data, but if i do this very fast, i have a high loss-rate, which i want to avoid. So i need to calculate the "correct" and stable data-sending rate.
softwarejaeger wrote:
Because i need to use UDP (that's it!)
So reimplement TCP using UDP. There is a reason for the functionality that exists in TCP. You can implement most of it via UDP. Read the TCP spec and read up on the algorithms in it. And one advantage there is that since the algorithms are self correcting there is no fixed interval.
-
Because i need to use UDP (that's it!) So... what i've done? I exactly realized that, what you told me. I check the correctness of the package, i check if the previous package is failing (and ask the other client for that package) and to "ii)" because that's why i have a sequential number in each data package. That isn't right, that the sending interval is irrelevant, because if i send data over the internet (behind two NAT) slowly, i get all data, but if i do this very fast, i have a high loss-rate, which i want to avoid. So i need to calculate the "correct" and stable data-sending rate.
Wow! You're expecting a lot for a protocol that doesn't guarantee delivery of packets at all, and get this, doesn't even guarantee that the packets will arrive in the order that you sent them! YES, it's entirely possible for packets to arrive in the wrong order! Believe it or not, what you're trying to do is rewrite TCP yourself.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak -
Well.. so for everyone, why i'm using UDP instead of TCP. First point: NAT (I need to make whole punching, because i need a P2P Connection) Second point: Latency (In a few cases, i doesn't need the whole "TCP" Features, i just want to send little messages) My protocol is doing exactly that and can all of kind like check for sequence, check for corrupcy and so on. But... i want the best performance and network bandwith load. So i need to calculate, how many packages i'm able to send, to not get a huge of requests back again.
The calculation you want isn't going to help because conditition change moment to moment. The limit that you calculate is no good the second you start sending packets and can change depending on network factors between to the endpoints.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak -
Hello, i have a problem with sending a lot of udp data over the network. Maybe somebody here, has to do with udp and can tell me, how to calculate the correct Udp-Datagram sending interval? My Datagrams contains a Class "DataFragment" which contains a continuous number (Package 1,2,3...n). If package 4 is here i check, if package 3 is here. If not i'll send a request to the other client back and it will send me the DataFragment again. This sounds fine, but it doesn't work very well. I need to ajust the send interval of my "output-stack". Has anybody a solution for this problem? (And please... no answers like "use TCP instead of UDP" and so on.) Thank you
I've done things like this with much lower level protocols. Typically I do it with ACK messages, so you send one UDP frame, then wait for the receiver to ACK before you send the next. It works well if you don't have time sensitive stuff like sending video. If you have to optimize due to lag or timing constraints, you could frame your own message protocol inside the UDP frame that would include a sequence number. That method will allow the receiver to send NACK messages (Negative ACK if you didn't know) on messages that it didn't receive. I think you'll definitely have to ACK messages in some way weather it's on every message or missed ones. Hope it helps. EDIT: After re-reading your original post, maybe your protocol includes ACK/NACK. One other thing you could do is try to optimize the size of the frame you're sending so that it fills as much of the frame as possible. Look up Minimum Transmission Units or something like that. You may also want to look at waiting for the order of arrival. Your sender just sends and sends, and the receiver can ask for specific frame numbers. You could eliminate any kind of artificial turnaround wait times. It would be up to the sender to buffer and sequence packets in some way that is saved or can be calculated for retries, and up to your receiver to be able to continue to receive in spite of out of order data.
"Simplicity carried to the extreme becomes elegance."
-Jon Franklin -
I've done things like this with much lower level protocols. Typically I do it with ACK messages, so you send one UDP frame, then wait for the receiver to ACK before you send the next. It works well if you don't have time sensitive stuff like sending video. If you have to optimize due to lag or timing constraints, you could frame your own message protocol inside the UDP frame that would include a sequence number. That method will allow the receiver to send NACK messages (Negative ACK if you didn't know) on messages that it didn't receive. I think you'll definitely have to ACK messages in some way weather it's on every message or missed ones. Hope it helps. EDIT: After re-reading your original post, maybe your protocol includes ACK/NACK. One other thing you could do is try to optimize the size of the frame you're sending so that it fills as much of the frame as possible. Look up Minimum Transmission Units or something like that. You may also want to look at waiting for the order of arrival. Your sender just sends and sends, and the receiver can ask for specific frame numbers. You could eliminate any kind of artificial turnaround wait times. It would be up to the sender to buffer and sequence packets in some way that is saved or can be calculated for retries, and up to your receiver to be able to continue to receive in spite of out of order data.
"Simplicity carried to the extreme becomes elegance."
-Jon Franklincarbon_golem wrote:
That method will allow the receiver to send NACK messages (Negative ACK if you didn't know) on messages that it didn't receive.
And how exactly is it going to make that determination?
Just say 'NO' to evaluated arguments for diadic functions! Ash
-
carbon_golem wrote:
That method will allow the receiver to send NACK messages (Negative ACK if you didn't know) on messages that it didn't receive.
And how exactly is it going to make that determination?
Just say 'NO' to evaluated arguments for diadic functions! Ash
You have to be aware of the sequence number. It will be up to the receiver to keep track of what it has and to identify missing frames. 1,2,3,4,5,6, 7-MISSING ,8,9,10,11, 12-MISSING... etc. A quick scan through the list and you'll find the missing frames (7 and 12). The receiver would have to request that those two be resent. If all frames were ACK'd the sender is waiting for a confirmation and is waiting to send the next one in line. I've worked with systems that function like this, and the ACK-on-every-message is woefully slow on high latency networks. You just have to send and hope it gets there, and put in provisions to resend frames later on down the road. You could also pre-parse the data that is to be sent and create a manifest of sorts that is sent first. If you know exactly what to expect in a data transfer the problem gets a little easier I think.
"Simplicity carried to the extreme becomes elegance."
-Jon Franklin -
You have to be aware of the sequence number. It will be up to the receiver to keep track of what it has and to identify missing frames. 1,2,3,4,5,6, 7-MISSING ,8,9,10,11, 12-MISSING... etc. A quick scan through the list and you'll find the missing frames (7 and 12). The receiver would have to request that those two be resent. If all frames were ACK'd the sender is waiting for a confirmation and is waiting to send the next one in line. I've worked with systems that function like this, and the ACK-on-every-message is woefully slow on high latency networks. You just have to send and hope it gets there, and put in provisions to resend frames later on down the road. You could also pre-parse the data that is to be sent and create a manifest of sorts that is sent first. If you know exactly what to expect in a data transfer the problem gets a little easier I think.
"Simplicity carried to the extreme becomes elegance."
-Jon FranklinYes, but the receiver does not know they are missing until the next one arrives. It then has to go through a retransmit sequence to get that message, which may, or may not be delivered. Running a protocol like this defeats the purpose of UDP and also adds a lot of host processing overhead which TCP handles at a much lower level. I think the OP is making a rod for his own back in following this route.
Just say 'NO' to evaluated arguments for diadic functions! Ash
-
Yes, but the receiver does not know they are missing until the next one arrives. It then has to go through a retransmit sequence to get that message, which may, or may not be delivered. Running a protocol like this defeats the purpose of UDP and also adds a lot of host processing overhead which TCP handles at a much lower level. I think the OP is making a rod for his own back in following this route.
Just say 'NO' to evaluated arguments for diadic functions! Ash
You're exactly right. Why UDP is insisted upon is baffling.
"Simplicity carried to the extreme becomes elegance."
-Jon Franklin