Will traffic shaping work based on source ports?
-
I'm shaping for some online games traffic in 1.2.3 and was just wondering about some things.
The game will always use a random dynamic source port when establishing connections to the servers. The destination ports are always the same. So it's easy to shape for the outbound queues.
However, when the server sends data to the clients, the destination port is the same random port. BUT the source port is always the same as the destination port used when the client contacts the server.
At least as far as I can tell from the state tables in both pfSense and IPcop, data always enters and leaves the online servers on the same ports.I understand that since the queues do keep states, there generally isn't an issue even if the inbound queues are shaping via the destination ports. What I'm curious about is whether the inbound shaping can use source ports rather than destination ports? And is there any reason to believe it won't work?
In IPcop, I had to shape based on source ports on the inbound queues because it wouldn't catch based on the destination ports. So I'm wondering if I have to do the same for pfSense.
-
why u confusing source port, while the destination port will be always the same ???
-
why u confusing source port, while the destination port will be always the same ???
I'm sorry but I don't understand what you mean by that.
For the online games, I'm refering to, traffic can be classified as follows:
Outbound from Game Client to Server:
Source Port: Random
Dest. Port: FixedInbound to Game Client from Server:
Source Port: Fixed
Dest. Port: RandomI'm not entirely sure how the traffic shaper in PFsense works but using the dest. port to shape inbound traffic didn't work at all in IPcop for me.
I'm wondering if there are any differences in Pfsense so I don't need to shape via source ports for inbound traffic. -
no brow…. u misunderstood.... u should clear about linux method first...
wan->lan source * dest 11-99
Lan->Wan source * dest 11-99see ? the destination always same port
-
no brow…. u misunderstood.... u should clear about linux method first...
wan->lan source * dest 11-99
Lan->Wan source * dest 11-99see ? the destination always same port
Ah… I see where you're coming from. That holds true for most games. Particularly those where you can change the ports used (Battlenet, Halflife etc).
The thing is, for the online games I'm referring to, the WAN->LAN traffic uses a random port to connect to the game (due to NAT traversal). The main thing is the original source port from the server remains constant (shows up that way in PFsense state tables too)eg.
Client -> Server traffic:
Source port: Random Dynamic Port (between 49152 - 65535); let's use 45000 as an example
Destination port: 18000 (fixed)Server -> Client Traffic:
Source port: 18000
Destination port: Random Dynamic Port (between 49152 - 65535); in this instance it will be 45000 -
hhhmmm get clearer now….
if there are random ports, so how about they static IP ?
-
hhhmmm get clearer now….
if there are random ports, so how about they static IP ?
I thought of that first, apparently, they own multiple IP blocks across an entire /24 range.
And to make things complicated, game updates are rolled off the same servers except on different ports. So far, I have the shaper shaping the inbound via matching the source ports.
It seems to work, at least according to Status: Queues and the fact that I don't have angry customers trying to kill me when someone goes crazy streaming videos.
RRD graphs are totally shot for tracking the queues on inbound traffic though. -
can u tell me what that game name is? or url maybe….
i want to try it by myself :) -
can u tell me what that game name is? or url maybe….
i want to try it by myself :)There are quite a number of free to play online games. Mostly by Nexon. There are different game service providers in different regions though. You can try Maplestory or Audition for starters.
Not quite sure which service provider (game distributor) would be for your region. -
I'm not sure if this where I need to post this, but I can understand your concern, because I'm trying to cache Audition patches but the problem is like what you have stated, it's patches/updates are coming from different ports everytime it updates/patches the client program. Other game clients such as Special Force, Warrock uses port 80, and therefore can be cache. Anyone here who has succeeded in caching online game patches that passess thru ports other than port 80?
-
My observations is that inbound traffic shaping is problematic at best, so I wouldn't invest any real effort in that.
-
My observations is that inbound traffic shaping is problematic at best, so I wouldn't invest any real effort in that.
I don't quite shape the inbound traffic in the sense that I want to prioritize them (not possible as far as I can see) more like segregate traffic into "penalized" (upperlimit set, 1Kb realtime, 1% bandwidth share) and non-penalized queues.
Effectively, I'm simulating a lower bandwidth connection for the non-games traffic.
The games use a mixture of UDP and TCP so I just need to classify them into another queue (higher priority in the shaper, no upperlimit). This causes the shaper to drop packets on the penalized queue in favour of the games queue.
-
I'm not sure if this where I need to post this, but I can understand your concern, because I'm trying to cache Audition patches but the problem is like what you have stated, it's patches/updates are coming from different ports everytime it updates/patches the client program. Other game clients such as Special Force, Warrock uses port 80, and therefore can be cache. Anyone here who has succeeded in caching online game patches that passess thru ports other than port 80?
Don't bother trying to cache the patches.
It's faster (if you have a gigabit network) to just copy and overwrite the entire game folder on the other computers that need patching. -
how much bandwidth are we talking about here sir? i got the same delimma as yours and i'm stuck on a 384kbps for 6 PC. ;D
-
I've got about 2700kbit/s of downstream (after overheads) to go around 36 clients. :-[ Let's not even consider upstream.
Gaming traffic is actually quite minimal (<30Kbit/s per client; more if the client is a game host)
It's a matter of managing the other services (web surfing, streaming youtube/ tagged videos etc) so that they can't saturate the line. Line saturation is a big culprit in making latencies skyrocket.
Since most of the services being capped either use TCP (able to re-transmit, responds to ECN) or have buffers (streaming videos), dropping the packets on the downstream to force the source to throttle back actually works remarkably well.
Comparatively, most online games use UDP (TCP is used only for authentication) and don't have netcode optimized for lag compensation and interpolation (like Halflife engine), dropping/ limiting the packet stream is out of the question.