Zeni have you considered....

eyesreye

trying UDP instead of TCP for Combat/Movement etc?


Anyone with better knowledge about this and if it's a possible solution to the performance issues?

Goregrinder

Well UDP doesn't check to make sure packets got to the other side safely. How would that make combat better?

relentless_turnip

Goregrinder wrote: »

Well UDP doesn't check to make sure packets got to the other side safely. How would that make combat better?

I don't know the difference in this area I'm totally ignorant.

I would like to add my packets don't arrive safely ... They don't even leave the depot 😭

katorga

TCP and UDP perform error checking. TCP corrects errors within the protocol, and UDP discards errors or shifts the burden on error correction to the receiving application code.

TCP is a connection based protocol and UDP is connectionless.

TCP has higher protocol overhead than UDP. Headers are larger, and every connection requires the 3 way handshake to setup. It is one of the reasons that SSL/TLS VPNs are transitioning to UDP port 1194 vs TCP 443. Speed. They shift error control to the VPN application rather than the transport protocol.

If ZOS moved to UDP, they would need to build in error checking and correction in the client and server code. Otherwise the game would not function.

eyesreye

It should still be faster than TCP right? even when they have to implement their own way of dealing with lost packets etc.

TheImperfect

I don't think it's a good idea.

QuebraRegra

Goregrinder wrote: »

Well UDP doesn't check to make sure packets got to the other side safely. How would that make combat better?

would you believe that NASA uses UDP for spacecraft commanding, etc.? Allow me to tell you about RTP sequencing in UDP... Better yet, google it. Reliability checks can be made at the application layer when checking RTP sequencing. Even auto-retransmission of frames, and "command echoes" can be implemented using UDP to provide reliability.

Consider if you will the gaming industry in general, and consider how many online games and MMOs use UDP versus TCP.

I rest my case.

QuebraRegra

eyesreye wrote: »

It should still be faster than TCP right? even when they have to implement their own way of dealing with lost packets etc.

faster and generally less "overhead".

To go along with that, much should be moved to client side, versus server side.. at least for PVE.

QuebraRegra

katorga wrote: »

TCP and UDP perform error checking. TCP corrects errors within the protocol, and UDP discards errors or shifts the burden on error correction to the receiving application code.

TCP is a connection based protocol and UDP is connectionless.

TCP has higher protocol overhead than UDP. Headers are larger, and every connection requires the 3 way handshake to setup. It is one of the reasons that SSL/TLS VPNs are transitioning to UDP port 1194 vs TCP 443. Speed. They shift error control to the VPN application rather than the transport protocol.

If ZOS moved to UDP, they would need to build in error checking and correction in the client and server code. Otherwise the game would not function.

Well said. That error checking and correction at the application layer is easily doable.. and has been done for years by agencies using UDP for what might be considered "critical" communications. The whitepapers and models are out there... it's literally not rock science anymore

Goregrinder

katorga wrote: »

TCP and UDP perform error checking. TCP corrects errors within the protocol, and UDP discards errors or shifts the burden on error correction to the receiving application code.

TCP is a connection based protocol and UDP is connectionless.

TCP has higher protocol overhead than UDP. Headers are larger, and every connection requires the 3 way handshake to setup. It is one of the reasons that SSL/TLS VPNs are transitioning to UDP port 1194 vs TCP 443. Speed. They shift error control to the VPN application rather than the transport protocol.

If ZOS moved to UDP, they would need to build in error checking and correction in the client and server code. Otherwise the game would not function.

Hm yeah very true, does anyone know if ZOS has room to hire the talent required to make this happen and pay those people's salaries within their 2021 budget? How many people would it realistically take to make this happen without breaking the game, and what would the average amount of time would it take for them to make this change based on other MMORPG's that use UDP?

milllaurie

QuebraRegra wrote: »

Goregrinder wrote: »

Well UDP doesn't check to make sure packets got to the other side safely. How would that make combat better?

would you believe that NASA uses UDP for spacecraft commanding, etc.? Allow me to tell you about RTP sequencing in UDP... Better yet, google it. Reliability checks can be made at the application layer when checking RTP sequencing. Even auto-retransmission of frames, and "command echoes" can be implemented using UDP to provide reliability.

Consider if you will the gaming industry in general, and consider how many online games and MMOs use UDP versus TCP.

I rest my case.

Nasa does this because it takes too much time to do the check on Earth. Keep in mind - radio communication is capped at light speed and it can take up to a few minutes if the spacecraft is far enough.
Also nasa is not purposefuly sabotaging itself. I am talking about cheating of course. When you can send false information about your whereabouts.

Ranger209

katorga wrote: »

TCP and UDP perform error checking. TCP corrects errors within the protocol, and UDP discards errors or shifts the burden on error correction to the receiving application code.

TCP is a connection based protocol and UDP is connectionless.

TCP has higher protocol overhead than UDP. Headers are larger, and every connection requires the 3 way handshake to setup. It is one of the reasons that SSL/TLS VPNs are transitioning to UDP port 1194 vs TCP 443. Speed. They shift error control to the VPN application rather than the transport protocol.

If ZOS moved to UDP, they would need to build in error checking and correction in the client and server code. Otherwise the game would not function.

So let me ask you this, and maybe it is a nonsensical question, or maybe it's not. Is TCP more negatively affected by the systems of its clients? In other words if more people using low end systems are involved and those individual clients can not process the requests in a timely manner does it have a negative impact on the server, or is the impact felt only by each individual client based on its own ability to send and receive those requests? I guess what I am trying to understand is how much of the latency we experience is a result of the servers capacity to process the data vs. the capacity to transfer that data between server and all of the individual clients, particularly when the processing power of some of those clients may be less than adequate. If that is so would it not matter whether TCP or UDP is employed in that regard, or does UDP help get around this issue if in fact it is an issue. A follow up question to this is does the fact that so much of the calculation process has been moved to the server now mean that a significant number of requests has been increased or decreased to transfer the data? Would that be unaffected by the fact that so much of the data calculation is now server side?

If these questions are beyond your scope of the subject I apologize. And again they may in reality be nonsensical questions that really have no basis on how the data is transferred, processed, and transferred back from client/server/client. Just trying to wrap my head around it.

jhharvest

Ranger209 wrote: »

So let me ask you this, and maybe it is a nonsensical question, or maybe it's not. Is TCP more negatively affected by the systems of its clients? In other words if more people using low end systems are involved and those individual clients can not process the requests in a timely manner does it have a negative impact on the server, or is the impact felt only by each individual client based on its own ability to send and receive those requests?

It depends on the implementation and is not strictly speaking a function of the protocol.

Let's look at these two severely simplified examples:
1) Server waits for client
Player A is moving but there are some fragmented packets so server requests retransmission from client A
Player B uses skill on player A
Because scenario is implemented so that server waits, this is delayed until client A retransmits and we can check if player B is in range of Player A. As a results player B feels like their skill isn't going off.

2) Server does not wait for client
Player A is moving but there are some fragmented packets so server requests retransmission from client A
Player B uses skill on player A
Because scenario is implemented so that server doesn't wait, it uses instead last known position of player A. This can lead to player A getting hit even though they were moving away from player B, so they feel like player B is lagsploiting.

Scenario 1 leads to the kind of issue we're experiencing currently but the source of the delays could be anything, not necessary net protocol.

(Also anyone with more protocol smarts than me please correct.)

Helgarth

I'm so sure no one asked the question while developing the game already.......

I'm a software engineer BTW...

Edit: Oh and btw, a game where they need to make constant changes for "performance tests" can't turn out fine... Never heard such a thing and never done such a thing... The die and retry thing should be while playing a video-game, not when coding it...