If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.
I think there is a difference in the rate at which Qrack and DP refresh pings to the scoreboard , and/or there is some type of averaging of pings going on.
Qrack could be reporting pings faster and more often. I could detect no difference in pings at Rage using DP vs Qrack.
I was under the assumption that if the "-ip" wasn't specified it fell back to INADDR_ANY
It does until this chain happens: _Datagram_SearchForHosts -> dfunc.Broadcast=WINS_Broadcast -> WINS_GetLocalAddress
as a test, start fte, set sv_listen_nq 1; dedicated 1; map start
in qrack/proquake/etc, do connect localhost:27500
if that fails when connect $NAMEOFMACHINE:27500 or whatever works, you have this bug. If you prefer, you can test with DP instead, of course... I think its 'sv_protocol quake' to get it vanilla-compatible.
try it.
if you bind to INADDR_ANY, you get packets destined for any interface that the local machine owns, yeah (any interface/alias, rather than any ip). it'll guess some local ip when sending packets based on the interface the packet is sent over, so you might not know the ip the other side will see, but you won't know that if you're NATed either, so no loss.
like I say, you don't always know the source ip in your outgoing packets. routing tables will mess this up even if you did try to guess. This doesn't affect clients, as the ips will always be the same for any remote endpoint. NQ servers listen on one socket, and host the game for each client on a separate socket. The server needs to report its local ip properly in order for the client to accept packets as from the server. The ip that is reported for the client to connect to instead is unaffected by this change, but the sender's ip is. The server's source IP may appear differently, but in cases where it is, both IPs are able to send to that client. If you're really paranoid you could explicitly bind the connected socket to the same ip that was reported to the client, but mneh, that's not gonna happen.
Comment