Reliable UDP implementation
Author
Greetings,
I''m on my way to implement reliable UDP in my network engine, but i have a few questions.
1. After implementing an ICMP echo, i''ve found that in localhost i''m only able to get latencies of 15 ms between a client and a server. After tracking the problem i found that my select() call was the problem. The maximum amount of time it''s allowed to spend in the select() call can never be lesser than 15.6 ms exactly. It''s on Win2k and i''m suspecting it''s related to the way Windows process scheduling is working. Unfortunately this select() only returns after 15.6 ms, i cannot reply to an ECHO packet in less than 15 ms. Any way to solve this ? Like having a select() working with 1 ms only ?
2. When a packet is lost it is resent after a bit of time. I''m currently using 15.6 ms due to the 1) requirement, but what should be the correct values ? Like in TCP, after which amount of time is a packet normally resent ?
3. Related to 1), in many games (like Unreal Tournament) one cannot get a ping lesser than 15-17 ms. I''ve always wondered why, is 1) the explanation ?
4. Regarding the checksum to detect corrupted packets, UDP uses a 16 bits checksum. In theory it''s possible that one gets a corrupted checksum, a corrupted chunk of data, and that even corrupted the checksum matches the data. I''d like to know what''s the probability of this kind of events, depending on the number of bits corrupted, the size of the data, the length of the checksum (how using a 32 bits checksum affect the probability of this) ? Any doc. or URL related to the topic is welcome.
5. I''m currently using a thread to handle networking events. In particular it usese a sent and a received packets queue. The user process interacts with that thread using classic send() and recv() functions. These must be thread-safe. I''d like to know if/how this is implemented in TCP. Is there a mutex per socket ? If so isn''t it a very significant overhead when dealing with, like 10000 connections ?
6. What is the average packet loss expected on a standard 512k ADSL line, under "pretty good" conditions ? Same question for "out-of-order" packets.
Thanks,
Y.
1. Don''t use select(), use Windows events. Set the socket to do async notification, and handle the events in your windowproc.
2. http://www.faqs.org/rfcs/rfc2988.html - TCP implementations maintain an average round trip time and a measure of the variation for each connection. The Linux and BSD kernels have done this properly for some time - check their code. If you''ve got licensing restrictions, check the BSD code.
3. Never looked - sorry.
4. Given that few people use SLIP on 9k6 modems these days, almost all datalinks are checked at the packet level - usually using a check mechanism that is considerably better tuned for the medium concerned than a generic checksum. In my experience, link errors are down below the 10 million to 1 level. Your netcard and DSL router may have error rate statistics on; check. Bluntly, it''s reliable enough for me as it stands, and I run business-critical apps across the Internet.
5. It''s done at kernel driver level (so mutexes are cheaper as they don''t involve context switches into the kernel). In the stacks I''ve seen, considerable effort is expended to make enough mutexes that threads typically aren''t blocked on the same one.
6. Depends on what''s upstream. If you''re contacting a server in Outer Mongolia whose net connection uses two tin cans and a piece of string, your packet loss will be high. Out-of-order packets occur comparatively rarely, as most routers forward on a first-in-first-out basis. You have to have alternate routes between the end systems before it becomes a real possibility. However, remember Sod''s Law: if you don''t handle it, it''ll happen.
[Line eater? What line ea
2. http://www.faqs.org/rfcs/rfc2988.html - TCP implementations maintain an average round trip time and a measure of the variation for each connection. The Linux and BSD kernels have done this properly for some time - check their code. If you''ve got licensing restrictions, check the BSD code.
3. Never looked - sorry.
4. Given that few people use SLIP on 9k6 modems these days, almost all datalinks are checked at the packet level - usually using a check mechanism that is considerably better tuned for the medium concerned than a generic checksum. In my experience, link errors are down below the 10 million to 1 level. Your netcard and DSL router may have error rate statistics on; check. Bluntly, it''s reliable enough for me as it stands, and I run business-critical apps across the Internet.
5. It''s done at kernel driver level (so mutexes are cheaper as they don''t involve context switches into the kernel). In the stacks I''ve seen, considerable effort is expended to make enough mutexes that threads typically aren''t blocked on the same one.
6. Depends on what''s upstream. If you''re contacting a server in Outer Mongolia whose net connection uses two tin cans and a piece of string, your packet loss will be high. Out-of-order packets occur comparatively rarely, as most routers forward on a first-in-first-out basis. You have to have alternate routes between the end systems before it becomes a real possibility. However, remember Sod''s Law: if you don''t handle it, it''ll happen.
[Line eater? What line ea
quote:Original post by Ysaneya
3. Related to 1), in many games (like Unreal Tournament) one cannot get a ping lesser than 15-17 ms. I''ve always wondered why, is 1) the explanation ?
That time probably includes the time it takes the server to process a packet and respond to it. 15-17ms per packet would mean the server is able to compute and send about 60-67 situation updates per second. I don''t think games actually go through all the trouble of doing out of band ICMP pings just for that measure, considering some routers tend to delay or even drop ICMP traffic when they''re busy enough with "real" data.
High-performance routers typically have a software engine for exception cases, and a programmable-hardware engine for common cases.
Thus, packets with status bits, or packets from sources or to destinations it hasn''t seen before, will be handled with the (slow) software path. Meanwhile, packets that are just continuations of previously established (virtual) sessions will go straight through.
Thus, a session open might easily cause the first packet to go up to software; the software re-writes the hardware for the connection, and then forwards the software-routed packet. Meanwhile, the second packet in the stream was already funneled through by the hardware, and you receive the second packet before the first packet, as an example.
Also, link-layer reliability protocols, used by microwave links and modems, may re-transmit packets out-of-order when there is loss.
A "good" connection typically gets 0.1-1.5% loss across all the links and backbones. I''d characterize a "bad" connection as one with 2% or more loss. I''ve seen as bad as 30, when microwave links and bad weather were involved, or when there''s significant congestion in some specific geographic area.
Thus, packets with status bits, or packets from sources or to destinations it hasn''t seen before, will be handled with the (slow) software path. Meanwhile, packets that are just continuations of previously established (virtual) sessions will go straight through.
Thus, a session open might easily cause the first packet to go up to software; the software re-writes the hardware for the connection, and then forwards the software-routed packet. Meanwhile, the second packet in the stream was already funneled through by the hardware, and you receive the second packet before the first packet, as an example.
Also, link-layer reliability protocols, used by microwave links and modems, may re-transmit packets out-of-order when there is loss.
A "good" connection typically gets 0.1-1.5% loss across all the links and backbones. I''d characterize a "bad" connection as one with 2% or more loss. I''ve seen as bad as 30, when microwave links and bad weather were involved, or when there''s significant congestion in some specific geographic area.
Might not be it, but make sure it's not your timer that only has a 15ms granularity...
[edited by - fenghus on April 22, 2004 6:53:04 PM]
[edited by - fenghus on April 22, 2004 6:53:04 PM]
3) They probably didn''t implement detection code for a local server, meaning that the client will still pump messages trough the network layer(winsock)(and consequently a part of internet), therefore you will not have a ping of 0.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
