OSDev.org

Hi consider the following

I have a UDP server binded to port 4000
port 4000 is also forwarded in the router's firewall and the system's firewall

I also have a UDP server binded to port 4001 but its a local server so its not forwarded in the router's firewall we don't want access out of the local network

now the UDP server is programmed to respond to the IP address and port of the packet sender. But the malicious user modify's the IP and UDP header and sets the IP to 127.0.0.1 and the port to 4001. Would this mean that the user has bypassed the firewall and has tricked the UDP server binded on port 4000 to communicate with the UDP server binded on 4001.


Or is their standard security in the firewall to dump packet's that attempt to use local address's as the sender IP

Many thanks

A router wouldn't route a packet with a source address of 127.0.0.1, would it?

Even if it's a very bad router and it will route the packet, the reply will be sent to... address 127.0.0.1

iansjack wrote:A router wouldn't route a packet with a source address of 127.0.0.1, would it?

no it wouldn't but if the machine has received this packet and attempt's to respond to it the network driver in the PC will cause it to loop back it will attempt to connect to its self not leaving the machine. So my question is does the router or machines firewall drop packets that have sender ip of 127.0.0.1. I need to figure this out because I need to write a protocol on top of UDP for my future online game. TCP is to slow. And I don't want to run into any nasty surprises

Even if the router does route the packet, and the OS accept the packet, which they shouldn't, any decent firewall should allow you to set rules to prevent packets with source IP 127.0.0.1 and source interface not lo from being routed in production. Have you actually tested your setup to see if there is a problem in the first place...?

computertrick wrote:I need to figure this out because I need to write a protocol on top of UDP for my future online game. TCP is to slow.

It has been very well studied that, for inter-server messaging over (multiple) giga-bit network, stock tcp is usually good enough - if you demand higher traffic it indicate you did something wrong (unless you are another Facebook or Goggle scale project).

With stock udp, although drop packet is rare, but in occasion scenario like server busy it may still happen; so you end up implement re-transmission, send/recv buffers, etc - aka reliable UDP. which assemble most of the TCP functionality.

However, can your reduced features set beat something designed by IETF greeks, implemented and optimized by Microsoft, BSD or linux community, is another story - you may beat them, with effort so huge that out-weight the game project.


As a side note, reliable UDP has also been studied for client-server transport, however due to problem with firewalls and routers and not justified benefit, it has not been widely adopted.

The deficiencies of TCP for realtime applications are already well documented.

Retransmission is one of them.

Owen wrote:The deficiencies of TCP for realtime applications are already well documented.

Retransmission is one of them.

However, for game servers, re-transmission is usually required to avoid lost of game states / game events.
At least it ease the design of server model by taking them out of question.

I can't use TCP its not reliable for the type of server I am writing. I am writing a game server.

And the source IP being 127.0.0.1 is just theory it just popped in my head. So is anyone sure that packets with sender IP of 127.0.0.1 will be dropped if they are coming in from the internet?

computertrick wrote:I can't use TCP its not reliable for the type of server I am writing. I am writing a game server.

Interesting. I designed & implemented a few commercial MMO game servers with TCP, I may have overlook the issue you encountered.
Can you explain further how TCP is not reliable for inter-server communication?

computertrick wrote:And the source IP being 127.0.0.1 is just theory it just popped in my head. So is anyone sure that packets with sender IP of 127.0.0.1 will be dropped if they are coming in from the internet?

Most firewall and router (at your side) and the server machine itself should be able to block such simple malicious packet, since "eth0" has no route to 127.0.0.1.

Furthermore, spoofing other player from port 4000, a responsible ISP (at sender's side) could ignore spoofing packet (of source field) from sender.

bluemoon wrote:

computertrick wrote:I can't use TCP its not reliable for the type of server I am writing. I am writing a game server.

Interesting. I designed & implemented a few commercial MMO game servers with TCP, I may have overlook the issue you encountered.
Can you explain further how TCP is not reliable for inter-server communication?

TCP is almost definitely going to get better throughput than UDP, unless you are doing something very clever and basically turning UDP into TCP. However, UDP will get much more consistent latency, because there will never be backoff or retransmission, and games want low latency, not high throughput. However, under almost all real conditions (with the good Internet connections we have today), TCP will be simpler to use and perform basically the same.

I thought a common client/server communication scheme used udp to send real time client "input" to server. For example, the client application processes user input and updates a character position according to game rules. It then just sends the updated position to the server. If the server considers the position it receives to be valid, then no further confirmation is needed. When the server misses a couple packets, it and the client need to resync. Hence the "jump backwards" you experience when you are lagging in games. That is the server correcting the client position. Up till that point, the client pretended to be right and sent all his updates to the server. The server missed enough of the update stream that it considered the client to be "wrong".

In the above case, tcp could just as easily be used and delayed packets would give similar effect as missed packets. However, if a delayed packet is an error and a missed packet is an error, why would you want the overhead of tcp? In short, I believe udp is a better option if (and only if) a delayed packet will be treated the same as a missed packet.

In the case bluemoon was describing of inter-server communication, I can not think of any major situations where tcp would be a problem that couldn't be solved by a better architecture.