Except glam log coding, and client server verification are 2 completely different things that take 2 completely different resources, not just network. glam log is also about storage and saving char data to storage, which is separate from the network connection you have to the server.Quote:
Originally Posted by Snow_Princess
What SE is talking about in regards to char data is moving chars between servers for duty finder, which is internal network, not external, and saving char data to the storage arrays, which again, is internal network, not external, and the network cards themselves do much of the "processing" of these network requests, so its not a server programming limitation. They also likely use different network cards for internal network, storage, and external network.
Game is way too picky when it comes to a single packet loss
Printable View
-
10-03-2017, 12:35 PMValkyrie_Lenneth
-
10-03-2017, 12:40 PMSnow_PrincessNot to SE, but that is likely cuz they do not know what people mean by a glam log, my guess is they see it as taking the same resource though? Regardless the point is the coding in this game needs fixing and changing. I really hope I found the proof in why it does...Quote:
Originally Posted by Valkyrie_Lenneth
One single packet loss causes an action to fail, i have never seen that from any other game I played online. -
10-03-2017, 12:42 PMValkyrie_LennethAgain, those are 2 separate things, and you did not show proof why the coding is bad, only that losing network connectivity causes gameplay interrupts.Quote:
Originally Posted by Snow_Princess
-
10-03-2017, 12:49 PMClaviusnex
Without knowing what is going on with the game's packets there is no way to determine where to start looking for the problem. You can't tell whether it is server side, client side, single packet loss, timeouts or any other number of things that could result in the unexpected closing of a connection. As I said packet loss with TCP connections should generally be recovered by a retransmission and my understanding is FF XIV is TCP based. It might not even be an issue with the game code. More than once I've had to debug problems in the Windows TCP/IP stack that appeared as errors to the application program. However it takes a sniffer to be able to diagnose what is really happening on the network for that connection and to provide enough information to do software diagnosis. Neither ping or traceroute will provide the needed data.
What are you basing this on? Pings don't prove this at all.Quote:
Originally Posted by Snow_Princess
-
10-03-2017, 01:02 PMMixae
I have good internet and a wired connection and I still notice you have to dodge things on point, even if you are technically out of it before it hits. I guess I'll try to use a ping booster and see if that helps, but im in US playing on a US server.
-
10-03-2017, 01:03 PMSnow_Princess
whatever, i suppose in your view saying nothing is better and it is better keep things the same.
I am here to suggest how to improve the game, what these forums are for, not to hear this can't be done or that.
We do not know the exact cause sure, but this game's coding is a problem, surely you saw situations of proof of that?
do a tracart, you might discover you have the same issue as me, simply bad routing.Quote:
Originally Posted by Mixae
-
10-03-2017, 01:26 PMClaviusnexI assume this is a response to me. I'm not saying nor have said there aren't problems with some of the game's design and/or code. However you keep going on with nothing more than saying fix it. I've told you what will be needed to proceed further with your problem. With the sniffer the exact network, client and server flows will be visible. This along with the time and game actions being performed can then be handed off to SE or whoever to do analysis. Until there is concrete data SE will continue to blow you off with instructions to run ping and traceroute then contact your ISP.Quote:
Originally Posted by Snow_Princess
By the way I had issues with WoW a few years back. They gave the same arguments about it being everything but them. My ISP claimed it was on my end. That changed when I gave them a sniffer of their server sending an unexpected FIN/ACK. My dropped connection issues went away. What they did to fix it I have no idea and they wouldn't say. They might have changed code, patched the OS or fixed a network/system performance problem. -
10-03-2017, 02:16 PMClaire_Pendragon
Lets try to explain what the OP is saying, in different words/examples.
(Since I have to go through the same thing as the OP)
If I pull my plug out, the game waits like 30 seconds or more, before it will say I have been disconnected.
In that period of time I can move around, and try to use abilities, but nothing happens, and i dont see players moving.
(This is how I know I get a true DC, not SE trying to DC me)
If I zone, Get moved through teleports, including raises, or someone leaves an instanced dungeon, leaving the group, I get DCed roughly 10% of the time.
But when I try to log back in, it says "You're still in the game"
That message only shows up, when your client kicks you from the game, but the servers think you're still on them.
Your client is incorrect, as you havnt lost connection, you can literally use an ability, see its effect, and see someone type messages none stop, all the way up till that black screen kick.
There was no actual disconnection, just the game THINKING there is, because of a small packet loss, at a weird time.
(This is ignoring needing the game to be more client side for certain things, like the mount, dodging AoEs, etc)
Just the idea of being kicked when "moving locations" isn't even an issue about client side, so much as its programmed to go into a panic, and kicks you over 1 lost packet.
(Technically there's more to it than that, because I can also not lose packets, and get kicked as well from zoning. I even have 2 versions of the game running on my same/single PC when my friend is over, he uses a controller, while i use a keyboard. We can both zone at the same time, but only one of us is being kicked, despite our connection being the same.)
The game is programmed to improperly handle the situation.
Other MMOs dont do this, so obviously they are doing something wrong. (Yes, I understand that the game servers are in a different location and go through different routes. Even so, the same issue happened in the prior server locations, when i was right next to them. Single packet loss, leads to a kick. Other MMos say "hey, l;ets wait 30+ seconds, and see if they come back from what we think is a DC".) -
10-05-2017, 09:13 PMClaviusnexQuote:
Originally Posted by Claire_Pendragon
You still can't say the problems are caused by one lost packet. Just because Ping shows a lost packet doesn't mean the TCP connections that are between the client and server will. Also if the TCP connection does detect a lost packet it will go into retransmission processing. This is all handled by the OS. If these don't work the connection will be closed with an error being returned to the application. Again the only way to determine if there really is a missing packet and more importantly what was the data in that packet is to run a sniffer. It shows everything going back and forth between the client and server and is what is needed to know where to start looking in the code. Look at it this way, not providing a trace is like calling your mechanic to have him fix a rattle in your dashboard without taking the car to them so they can look at it.
I did some poking around the other day with netstat. The client opens two connections to the server that remain open while the client is running. These are TCP connections so they are reliable transport. I have not looked at a trace but it seems logical to me that these connections are set up to allow full duplexing of client/server communications. It could also explain why server based information continues to be seen at the client but client actions stop working on the server while in limbo. I also noticed an occasional connection to a Google site. Since I use Google for my DNS my wild guess is these were DNS requests. This implies to me that the client can also open other connections when needed. Any one of these could be the cause of the problem. Without a sniffer there is no way to tell which. I rarely get disconnected and on the rare occasions I have I can usually attribute them to something like a DDOS attack. I might run some traces if I get bored just to see what goes back and forth between the client and server. Hopefully any text isn't in Japanese but I doubt I will be that lucky.
I understand it is not feasible to run a trace for something that occurs rarely but when someone can come close to reproducing a condition at will, as this thread implies, that is the time to do it. It is the only way to be able to perform problem determination and be taken seriously by the tech support personnel. By suggesting the sniffer I am just trying to help the affected folks progress beyond the simplistic blow off known as "Contact your ISP". And yes I hedge on the dropped packets as having close to 40 years in the business I know the last thing a tech support person or developer wants is to be told what's wrong with nothing to back it up. It tends to put them in a box and makes it harder to explain to the customer when they determine the problem is something else altogether.
Now back to painting the house.