Tweet
quakeworld use UDP to transfer files from server to clients. server sends a part of file,and then waits for an acknowledgement from client. it will cost a RTT time to send only a 768 bytes content. it is quite slow. is there any version of quake has improved the algorithm.
-
-
I have little understanding of the algorithms in quakeworld client/server but I think you have UDP confused with TCP. UDP communication can be bidirectional; but, the messages themselves are unidirectional. Basically when you send a message, you get no confirmation as to whether or not the message was delivered successfully. So the server and client do not wait for any acknowledgement. It just keeps sending packets. The RTT of a message over UDP protocol highly depends on hardware and on operating systems of communicating peers. But even taking these conditions into consideration even 100Mb network and Window XP can provide average RTT of one millisecond and Xp is a no-realtime OS. TCP on the other hand will take hundreds ms or more.
And UDP usually only gets up into the dozen range. But because it's a non-reliable protocol you will have packets that get lost in translation. This is where good netcode and good prediction algorithm comes into play.
So I guess I'm confused by your statement. Also Quake netcode acts like this, when the user holds down the forward input it is only when that input makes a round trip to the server and back to the client that the client’s character starts moving forward locally. It's great and easy code but has limitations and one of them is increased latency. QW came up with client side prediction to compensate for this problem. Client side prediction works by predicting physics ahead locally using the player’s input, simulating ahead without waiting for the server round trip. The server periodically sends corrections to the client which are required to ensure that the client stays in sync with the server physics. Now perhaps QW doesn't handle this prediction well. I have no idea because I haven't messed with the source code for QW. But the authors of FTE, equake, and maybe even LordHavoc sense DP can handle quakeworld protocol as well. Hopefully one of them can provide you with an answer. -
thanks for reply, I mean the netchan protocol based on UDP , Quakeworld only sends UDP diagram everytime. netchan protocol make a bit improvement to UDP, it can delivery reliable message via UDP, it has sequence and acknowledgement and timeout ,flowcontrol like TCP. but it seems without pipeline and slidewindow. so netchan transfer files at a very slow speed.Comment
-
Ah so essentially input goes into an unreliable sizebuffer, gets sent to the "netchan" and it forwards it into the diagram code. the code adds sequence and identification info and submits it to the socket code, the socket code sends it to the os and then on the server, the engine checks the netchan which checks the datagram, etc. Hmm... if this is the case I'm not sure if netchan is the real problem. I'd say its the diagram code would contain connection process and socket separation code for each client. That would be your weak link. But that's assuming alot. I just don't know enough about it. But one of these guys will jump in soon!
Comment
-
the vanilla protocol depends on the client to ack the last packet before another can be sent. using reliable messages, which require a round trip before the next can be sent. its basically 2 tiers of acks.
FTE has a 'chunked download' protocol extension, everything is unreliable which avoids the whole ack issue thereby greatly accelerating download speeds.
fodquake, ezquake, and mvdsv also implement it, but in subtly different ways, resulting in much finger pointing and paranoia between the devs involved.
download rates may still be limited by cvar settings even if the networking has infinite bandwidth and no latency. drate+sv_maxdrate can be adjusted to avoid this.Comment
-
how FTE controls its send speed . I have another idea, use a separated file tool to download file from a http fileserver. to avoid download file from quake server . but UDP file transfer still a nice idea.Comment
-
Some engines use curl (on a "sidechannel" I guess) for things like map downloads.Comment
-
I'm not kidding... That was harder than Quantum Physics! I really don't understand what's going on... All of you people are using complex terminology. I'm not used to these types of words. Can someone PLEASE explain to me in plain English what just happened? No offense, but what are you people talking about? I have an average IQ and I'm trying to learn something..."Through my contact lenses, I have seen them all, I've seen wicked clowns and broken dreams / Crazy men in jumpsuits trying to be extreme and messing around with your computer screen" - Creative Rhyme (03/23/2012)Comment
-
[ame]http://www.youtube.com/watch?v=ifv-3aSEckA[/ame]All of you people are using complex terminology. I'm not used to these types of words. Can someone PLEASE explain to me in plain English what just happened? No offense, but what are you people talking about? I have an average IQ and I'm trying to learn something..
exactly
What qw does is sends a portion of the file then asks the player's quake "did you get that?" then the players quake says yes or no then the server sends a little more then says "can you hear me now?", again and again.
FTE chunks out the whole pie and says, "in yo face!", then asks the player's Quake "what flavor of pie was that?"
etc...Last edited by R00k; 08-18-2014, 06:04 PM.Comment
-
yes, just like you sent only one people from U.S to Canada by airplane every timeComment
-
Do what i do, read first post then read first response then give up. I don't know anything about this crap so why even comment. This is why i am not into single player quake or Darkplaces, FTE and all these extra add-on/MOD style thing's because it makes no sense to me. I prefer to stick to what i know. Multiplayer NetQuake ;]Originally posted by RL Clown View PostComment
Comment