Playing from behind firewall

Networking & Multiplayer
#1

I’m making a multiplayer first person shooter. I haven’t come as far as doing testing yet, but I am conserned about wether it will work from behind a firewall.

The game uses udp. It’s a client/server architecture, with the creator running the server.

I’m considering trying to bind the listening socket to port 80, hoping this will allow the packets to go threw the firewall. Can this work? What do a run of the mill corperate firewall let threw? Is tcp more likely to work than udp? etc…

I’m a newbie at this so don’t bite my head off :slight_smile:

#2

Hi
Using port 80 could cause problems for running your server under linux, as you will need root permissions to run on a port under 1024.
UDP to port 80 will be no better than tcp to a high port, normally if outgoing traffic is locked down then it will be tcp to port 80 or 8080 only, (maybe port 25, 21 etc and some well known other ports will be open too, but no high ones).
On the other hand, if the high tcp ports are open, odds are, so are the UDP ones. This isn’t always true. Most companies/IT departments can realise that UDP is mainly used for streaming content like online radio, or for games, so it might be that all UDP is blocked, but TCP is fine.
As you can see, there is no common firewall setup, it’s up to the firewall admins at the end of the day as to what gets out. TCP 80 is the most likely to be open.
As for the person running the server, listening on port 80 is only any good if they have a public IP, or the firewall forwards the packets, so again, nothing is certain.

HTH

Endolf

#3

Corporate firewalls can be particularly restrictive.

As an example, our firewall ONLY allows outgoing or incoming connections via our http/ftp proxy.

HTTP is about the only thing you can gaurantee getting through a firewall.

Having said that, many firewalls allow outgoing TCP connections, but nothing else.

Using UDP you are least likely to get through a firewall, frankly. Some will allow outgoing UDP and then route incoming UDP addressed to the same socket back in, but its not common.

The one saving grace is that Java inherently supports SOCKS. Its a pain to set up but IF the user’s LAN has a SOCKS proxy AND they configure Java for it, then they are gold. (However the SOCKS proxy may add additional latency depending on how the LAN is set up and how overloaded the SOCKS server is.)

#4

This in turn means: forget UDP for online games?!

I thnik there are other points to consider when using UDP on the WAN. 90% or so of the traffic is TCP. For TCPs nature of being guaranteed … if I were a router and had to decide wether to drop a TCP or a UDP packet due to high load - I’d prefer the UDP one for I can be sure that I will see that TCP packet again. I experienced situations when playing around with JSDT/UDP, where the loss was 100% - which is absolutely legal for UDP :frowning:

So on the internet, you might expect higher packet loss on UDP! (Not sure wether that’s true).

I still am an advocate of TCP solutions esp. for the internet and by FlyingGuns can also proof they work just fine with low bandwidth needs and best opportunities for packet-avoidance-algorithms.

(um, did I start a TCPvsUDP discussion again or is it already here?)

#5

Hi
You started it again :slight_smile:
UDP is fine for games, ideal for movement when a packet lost here and there is not important, with TCP you would just flood the poor guy who’s connection is dodgy :). The specific question was to do with corprate firewalls, I don’t know anyone who plays things like quake from work to internet servers, maybe they play in the office out of business hours, but not normally across the internet. At home, UDP isn’t blocked by firewalls normally (IPTables and winblows firewall both let it all out by default), the are interested mainly in blocking incomming traffic (unless otherwise configured, at which point you know how to open certain bits up agian).

More general TCP v.s. UDP conversations should be directed at that long long thread over in the networking topics. But in terms of firewalls, from behind a corprate firewall as I commented and jeff confirmed, the most likely option is port 80 for client outgoing traffic, and UDP is the least likely. Running the server from behind the firewall will almost certainly not work at all though, regardless of what ports/protocol you use, that is after all the point of a firewall. The exception of course is where you are doing this for business reasons and you can get your IT dept to open/direct the appropriate ports/protocol at your server.

HTH

Endolf

UDP v.s TCP thread

#6

ROFL…Each of the huge corporates I’ve worked at has always had people playing Quake1/2/3 online. People tended to especially enjoy being LPB’s courtesy of a fast corporate net connection. One multinational headquartered in the UK where I worked used to suffer ethernet meltdown on Friday afternoons due to a combination of game traffic and porn-surfing (when the email servers broke one Thursday, and weren’t fixed until the start of the next week, an email was sent round saying that of the X thousand emails stuck in the queue for the past five days, something like 60% were non-business-related, and 20% could result in being fired according to the standard employment contract!).

Typically the game-playing is carefully moderated by the employees themselves - half an hour of quake during a lunch break every now and then gets tolerated, especially when people are arriving in work at 6:30am each morning. I’ve spotted even the most moralistic of employees doing it at some point or other :). I even have a friend who was somewhat embarrassed to be caught by his boss playing Quake and Solitaire at the same time :).

Um. We appear to be in the Networking topic? :). Anyway, I’ve made the TCP/UDP thread sticky, which should hopefully minimize accidentally going over the same ground!

[quote] But in terms of firewalls, from behind a corprate firewall as I commented and jeff confirmed, the most likely option is port 80 for client outgoing traffic, and UDP is the least likely.
[/quote]
…and which of course has led to the thriving business in HTTP-tunnelling options in various modern apps :), and the existence of articles with titles like “How to tunnel ANYTHING via HTTP”. Chuckle.

#7

Playing at work: this is a high potential market!! Esp. I think for casual Java games that are made highly attractive by MP features!

Minesweeper and Solitaire may be the most played games all over the world!! Not bc. they are good, but bc. they are playable at work in a fast-in-fast-out manner. Java games should try to get there!

Here in Germany there was the ‘Moorhuhn’ phenomenon - a game that got everywhere! Millions of copies! One reason was, I suppose, that it has been easily accessible at work!

(And for the other thing: I feel it is better to send a poor guy 1,2 or 3 TCP messages per second than flooding him with UDP packets where most of them get dropped. My personal feeling is that NOT sending data is by far better than sending with the risk of loss - but that’s fpr the other thread :slight_smile: )

#8

Don’t want to start the TCPvUDP discussion. My game is designed to use UDP and it works great.

However, casual gamers is the target group. It would be great if people could play it in their coffee break at work :slight_smile: So I might try connecting using as many ways as possible and use wathever works, if any at all. As for the TCP version I must make sure I don’t flood the line, because I’m using a quite brute force method :slight_smile:

#9

And to my disgruntled comment that HTTp tunneling is like locking the door and then trying to push the cat through the keyhole :frowning:

Once everything is tunneled through HTTP one has to question exactly why the main door was locked in the first place.

Typically the answer is that its an ugly, nasty, slow compromise born of corporate IT’s fundamental belief that no one but they should EVER be allowed to access the internet, and the real needs of their clients.

#10

Jeff: so something like compressing your data beforehand is somewhat akin to shredding the cat first? ;D

#11

[quote]Jeff: so something like compressing your data beforehand is somewhat akin to shredding the cat first? ;D
[/quote]
Or squeezing it into a key-sized mold :confused:

#12

Funny, a friend of mine just went through this sort of stuff trying to play Q3 at work. He could for the longest time, then some IT guy got mad for a completely different reason and decided to block the ports.

Had to switch to port 37 for the Quake server and he could get through again.
Our strategy was to find ports under 1024 that might use UDP for “normal” stuff… just so it would be unlikely that the IT guys would blockl those ports as well.

#13

Another issue here is ‘NAT’ routers (sometimes called NAT firewalls) - these can alter the outgoing port number, and in large organisations can even alter the lower byte or two of the IP between packets! If you reply roughly as many times as the client sends, it usually works out Ok. If the client can send many requests for each server reply, then it is advisable to check the IP & port of the most recent request received and reply to that instead of the initial IP/port umber you read. This does make client identification a little harder, and can allow spoofing of clients if you are not careful.

  • Dom