DarkPlaces running Quake protocol - single port?
Moderator: InsideQC Admins
5 posts
• Page 1 of 1
DarkPlaces running Quake protocol - single port?
When DarkPlaces is running the Quake protocol, is it using a single port (26000)? If anyone knows the answer?
/Thinking about taking another crack at implementing LHNET.
/Thinking about taking another crack at implementing LHNET.
The night is young. How else can I annoy the world before sunsrise?
Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
-

Baker - Posts: 3666
- Joined: Tue Mar 14, 2006 5:15 am
I would assume it uses only one port, like fte does.
note that the nq connection protocol contains both server address and port, so is still subject to router/nat issues with servers.
dp's q2-like connection protocol is better still.
but you can't use both at once, or things get confused. grr.
note that the nq connection protocol contains both server address and port, so is still subject to router/nat issues with servers.
dp's q2-like connection protocol is better still.
but you can't use both at once, or things get confused. grr.
- Spike
- Posts: 2892
- Joined: Fri Nov 05, 2004 3:12 am
- Location: UK
Spike wrote:I would assume it uses only one port, like fte does.
note that the nq connection protocol contains both server address and port, so is still subject to router/nat issues with servers.
dp's q2-like connection protocol is better still.
but you can't use both at once, or things get confused. grr.
Yugo2heck made a single port patch for Linux back about 8 years ago to solve some issues I brought up regarding NAT and did a server-side only fix. It only used port 26000.
I gets a bit irritating that both servers and clients are vulnerable to incorrect router settings since NetQuake is like the only game in the universe that uses multiple ports.
The night is young. How else can I annoy the world before sunsrise?
Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
-

Baker - Posts: 3666
- Joined: Tue Mar 14, 2006 5:15 am
Baker wrote:I gets a bit irritating that both servers and clients are vulnerable to incorrect router settings since NetQuake is like the only game in the universe that uses multiple ports.
There's a reason other games don't. :)
Which is kinda the point, its not 'incorrect settings', its 'default settings' that causes the problem. The way to fix the nat issue in NetQuake is to stop using more than one logical connection.
Servers are generally not behind nats, only firewalls. But because there's an address+port told to the client, the server program must know its world-visible address+port. It should be possible to restrict that to a cvar, with the a default empty setting meaning to guess, which will work for the majority of cases, but may still fail with multi-homed servers.
To be fair, when quake was released, nats were not quite as common as they are now.
Clients should just ignore the address given in the CCREP_ACCEPT completely, and use whatever the address it used for the request was. That'll fix the multihomed issue.
*looks at lhnet.c*
hmm, yeah that won't help you.
That's just a thin layer over the system's socket api. Its not really any different from net_wins.c
What you would need to port from dp is netconn.c (nq's equivelent being net_dgram.c).
The issue of single-socket comes down to NET_CheckNewConnections and NET_GetMessage. If you change those functions to permit the engine to use a single socket for all clients then its all fine and dandy.
But note that listen servers need to use more than just a single socket.
Look at a quakeworld engine's SV_ReadPackets function some time:
- Code: Select all
while (gotnewpacket())
{
if (packetiscontrolpacket())
dostatelessrequests(); //ie: checknewconnection
else
{
figureoutwhichplayer();
if (messageisacceptable())
readmessage();
}
}
of course, NQ has to deal with fragmentation.
If you want code chunks from FTE, SVNQ_ConnectionlessPacket+NQNetChan_Process+Netchan_Transmit(nq part) provide all server parts of nq transport compatibility. That doesn't include the client parts to generate/respond to requests though.
Frankly, the two ways are to either rewrite the code to basically kill net_dgram, reimplementing the parts needed (as both FTE and DP appear to have done), or alternately to hack the socket code to buffer lots of packets based upon sender, which may have flood issues.
- Spike
- Posts: 2892
- Joined: Fri Nov 05, 2004 3:12 am
- Location: UK
Thanks for the extra info to look through and understand.
Yugo2Heck once did a very technical explanation (well beyond me) of why his single port server patch fro Linux could never been implemented in Windows/Winsock.
So it appears that this isn't just a port issue but to truly fix involves at a minimum a "compound" solution with multiple factors.
At least I now understand that the port issue itself is not the only factor, which helps explain some other things in context. I'll have to go through this and the other accumulated posts you have done on similar topics in this forum and start examining some things.
Yugo2Heck once did a very technical explanation (well beyond me) of why his single port server patch fro Linux could never been implemented in Windows/Winsock.
So it appears that this isn't just a port issue but to truly fix involves at a minimum a "compound" solution with multiple factors.
At least I now understand that the port issue itself is not the only factor, which helps explain some other things in context. I'll have to go through this and the other accumulated posts you have done on similar topics in this forum and start examining some things.
The night is young. How else can I annoy the world before sunsrise?
Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
-

Baker - Posts: 3666
- Joined: Tue Mar 14, 2006 5:15 am
5 posts
• Page 1 of 1
Who is online
Users browsing this forum: No registered users and 1 guest