Bug 4428 - dynamic net_port for NAT gaming
Status: RESOLVED WONTFIX
Alias: None
Product: ioquake3
Classification: Unclassified
Component: Misc
Version: GIT MASTER
Hardware: PC All
: P3 normal
Assignee: Zachary J. Slater
QA Contact: ioquake3 bugzilla mailing list
URL:
: 4482
Depends on:
Blocks:
 
Reported: 2009-12-23 17:38 EST by tinkah
Modified: 2011-02-08 13:24:42 EST
1 user (show)

See Also:


Description tinkah 2009-12-23 17:38:19 EST 
port in net_port for clients can be changed to 

49152 + rand() / (RAND_MAX / (65535 - 49152 + 1) + 1)

//according to c faq answer http://c-faq.com/lib/randrange.html

that way people don't have to wonder why they can't game on same IP and the range 49152 - 65535 should be ok since it's also considered a 'dynamic' range.
Comment 1 tinkah 2009-12-24 09:32:17 EST 
some rudimentary discussion and code here http://forums.urbanterror.net/topic/19618-dev-idea-fixworkaround-for-net-port-on-same-ip/#entry248441
Comment 2 tinkah 2009-12-24 09:59:47 EST 
3 thoughts:

a) IDing each client packets might be a clean non-workaround solution but I don't know whether that'd be a source of heavy resources load or latency

b) Using Server port to 27960 + 1 and only Client port to <random> might create a problem with non-dedicated UI-started servers.

c) b) might be simply fixed if UIs of games simply ask for the port of the game on UI and set it like that.
Comment 3 tinkah 2009-12-31 14:04:03 EST 
oh, it might be solved easily if net_port is randomized only on connect and not on start server.
Comment 4 Zachary J. Slater 2010-10-19 02:20:29 EDT 
*** Bug 4482 has been marked as a duplicate of this bug. ***
Comment 5 Thilo Schulz 2011-02-08 13:24:42 EST 
I'm sorry. To change this, you'd need significant changes to the way sockets are opened and handled.
I tried going through this in my head, but there's no easy way to do this. You'd need to either:
close/reopen the socket before a connect to a server and bind to a random port, and close then reopen the socket with standard port given in net_port after disconnect. Or you would have to open a second ipv4 socket for the client part, and add this one to the select syscall and also make sure it reads from that socket.
Users can work around this by manually setting net_port to a different value. Yes I realize it's not very user friendly. Maybe you can send a patch and if it's reasonably clean I'll accept it.