Per application packet prioritizing, combat lag while downloading
Maybe not directly relevant to this forum, but I believe that people here might have the answer. Mods can feel free to move it, however the chance of successful answers probably lies here.
The old problem of downloading while playing games is that the download can suffocate the games bandwidth, and produce lag.
Games generally require very low bandwidth (~3kbps) which means that on a 512mbit connection, there should be another 61kbps left to download with. Even if some kind of limiting is imposed on the download, to reduce it to say half that; 32kbps, the game will still suffer (although this behaviour is a bit unpredictable). The reason as I understand, is that the packets from both the download and the game have the same priority, so they have to go through the same queues and processes in a 'one after the other' manner. Note that these IP packets are on a lower level than TCP/IP or UDP, so there is no distinction as to what protocol either application is using.
The solution as I see it (if I understand the problem correctly) is to provide a method to set certain applications packets to have a higher priority so that they can skip the queue. If a game's packets are set to high priority in this way, then every time the game requests to send a packet, it will be the first packet sent, and not queued up with other packets of the downloading program. This means that there is no need for bandwidth throttling on the download (especially since it doesnt usually help, because even if download is half speed, as long as packets are equal and queued, then the impact on the games packets can be almost identical).
In terms of a solution, I think this might require some very low level dealings with winsock, system hooking/hacking. But is there already such a program that allows this? If not, would it be possible to somehow create one?
A while ago I read someone explain this problem almost identically, and stated that linux gurus can customize a linux box running as a router, so that this kind of priority is given on a per host basis. So one person connected to the router can be downloading at max speed, and another person playing, and the playing persons packets will recieve max priority with no queueing etc. This obviously has an extremely minimal impact on the download, while the game behaves 100% lag free.
What I think is needed is this ability, but on a per application basis. Basically a program, where you select which application is the game, and then all packets sent by that program will be high priority.
Please post your feedback,
T
I can't imagine that an operating system developer would want to put this sort of power into the hands of application developers, as it opens up the system to all sorts of local denial of service attacks.
No doubt someone will post a Win32 API for it shortly then. ;)
No doubt someone will post a Win32 API for it shortly then. ;)
I think that is what QoS (Quality of Service) is supposed to do in Windows 2000/XP. I've never tried to use it so I can't tell you if it is particularly well suited to your application.
Sometimes the QoS network service (QoS Packet Scheduler) is not installed one some/all network interfaces, so using it may not be guaranteed to work. I believe some tweaking software will get rid of it due to a fear that it takes 20% of bandwidth away (not entirely true).
Heh. IIRC the way it's implemented, QoS will only take up to 20% of total bandwidth for prioritized applications (thusly aforementioned fear), so I should think it would be rather difficult to cause denial of service.
Sometimes the QoS network service (QoS Packet Scheduler) is not installed one some/all network interfaces, so using it may not be guaranteed to work. I believe some tweaking software will get rid of it due to a fear that it takes 20% of bandwidth away (not entirely true).
Quote:No doubt someone will post a Win32 API for it shortly then. ;)
Heh. IIRC the way it's implemented, QoS will only take up to 20% of total bandwidth for prioritized applications (thusly aforementioned fear), so I should think it would be rather difficult to cause denial of service.
Quote:Original post by jflanglois
I think that is what QoS (Quality of Service) is supposed to do in Windows 2000/XP. I've never tried to use it so I can't tell you if it is particularly well suited to your application.
Sometimes the QoS network service (QoS Packet Scheduler) is not installed one some/all network interfaces, so using it may not be guaranteed to work. I believe some tweaking software will get rid of it due to a fear that it takes 20% of bandwidth away (not entirely true).Quote:No doubt someone will post a Win32 API for it shortly then. ;)
Heh. IIRC the way it's implemented, QoS will only take up to 20% of total bandwidth for prioritized applications (thusly aforementioned fear), so I should think it would be rather difficult to cause denial of service.
This seems to be what I am looking for, I didnt realise QoS had an api n all, I thought it simply reserved some bandwidth from downloading etc, which as I mentioned doesnt really help, except against completly suffocating a program from bandwidth.
But it seems like it does have facilities for packet prioritisation etc, but it seems to me as if it is just a service for dealing with it, and an API if you want to make your program use it. Now I just hope its possible to make non QoS applications have QoS handling on them regardless; ill check out the AP.
For QoS to work you need to make a QoS-capable device the bottleneck in your connection. Most devices have send and receive queues and you want them all to be empty to make QoS work.
You can configure a linux-router to throttle all traffic to 90% of the theoretical throughput of the connection and then use the QoS-queueing on the linux-router.
You can configure a linux-router to throttle all traffic to 90% of the theoretical throughput of the connection and then use the QoS-queueing on the linux-router.
An alternative when you control the server is to dribble out data at a pre-measured rate.
An alternative when you control the client is to only read out data at a pre-determined rate, which means that the TCP window will fill up and throttle downloading.
An alternative when you control the client is to only read out data at a pre-determined rate, which means that the TCP window will fill up and throttle downloading.
I'm not entirely convinced that using TCP, you have enough control to prevent this problem. You'd have to use UDP for map downloads (along with the issues that this presents, like having to have a retry system to compensate for lost packets).
Yes - dribble the map out in small(ish) packets so that you don't hog the line for the other players who are still playing; only upload the map to one client at once.
Mark
Yes - dribble the map out in small(ish) packets so that you don't hog the line for the other players who are still playing; only upload the map to one client at once.
Mark
You do have enough control with TCP, especially on the server side. You can turn off Nagle, so it'll send whatever you send() or write() on the socket. send() little 400 byte pieces of data at a time, and that's what will go over the wire. Time it to whatever bandwidth you wish to use.
If you get a packet drop, the kernel may decide to coalesce pending packets in the re-transmit, but you can often turn that off (on Linux, it's in /proc/sys/net/).
If you get a packet drop, the kernel may decide to coalesce pending packets in the re-transmit, but you can often turn that off (on Linux, it's in /proc/sys/net/).
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement