POL News: All Worlds Maintenance

Actually, as a possible alternative, I would be happy to explain why corrupt encrypted files are unencryptable, but only if you answer my question about where the corruption occured. ;)

lol

(damn.. one hour until i get off work grrr... counting.....)
 
Very good point... :)

When you are doing layer 4-7 load-balancing and/or traffic shaping in the internet cloud (or backbone if you'd call it), it's really hard to determine what goes wrong in the traffic.

It would be nice if we can call the Japanese technical team and trouble shoot directly with them - no doubt.

If Art would answer my question would could tell if it's the route between the hosts that's corrupting the data or the actual encrypted data itself is corrupted which means it must be on SE's end.

His assertion is a VERY important clue, if true.
 
Actually, as a possible alternative, I would be happy to explain why corrupt encrypted files are unencryptable, but only if you answer my question about where the corruption occured. ;)
Tamper resistance? Nodes presume corrupted packets have been tampered with, and thus discard and re-request?

I know sweet F-all about encryption but you've aroused my nerd boner.
 
Interesting fact: pay the premium warranty price, and Dell upgrades you to white technicians homed in the one-and-only fantastic craphole, Calgary Alberta!

Ow...I'm from calgary :(
 
If you took them four years ago, we should technically be on the same page. I completed my CCNP courses in June 2003.
I bet you took all of them, though. The school I went to only paid for CCNA1 and 2 =/
 
Interesting fact: pay the premium warranty price, and Dell upgrades you to white technicians homed in the one-and-only fantastic craphole, Calgary Alberta!

Well... I can't verify they're all white. But I find it pretty damn funny that you have to pay extra to get support from people on your own continent.

LOL

damn.. i'm getting a very good laugh out of this tread here lol thank you SE!
 
Occam's razor - The principle states that the explanation of any phenomenon should make as few assumptions as possible, eliminating, or "shaving off", those that make no difference in the observable predictions of the explanatory hypothesis or theory. This is often paraphrased as "All things being equal, the simplest solution tends to be the best one."

You shouldn't need the cast of CSI to come here and tell you that since these problems occured immediatly following the update, more than likely there is a correlation there. Is it possible that it's a complete coincidence? Sure it's possible, but not probable. It could have been aliens tampering with your connection, or maybe Nixon's ghost, but the simplest deduction would be that it came as a direct result of the update.

I haven't had these problems yet but i've seen alot of others that have. It is not a dat issue for one. I have seen one day playerA cannot enter Port Jeuno without R0'ing and getting DC. The very next day they can, but then it happens in Ru'Lude Gardens. If it were a dat issue, that would not mysteriously fix itself.

You IT guru's can speculate all you want on what the problem is but that's pretty much all it is is speculation. It's possible that something completely unrelated happened the exact time of the update to cause these problems and is only affecting a random percentage of players, regardless of what system they play on, who their provider is, what geographic region they live in, etc, etc, but is that really likely enough to argue it like a pitbull with a piece of meat?

Argueing that since it's only a small percentage and not the whole doesn't really hold water either btw. Have you ever seen when a car manufacturer orders a recall? Usually it's only something like 5% that have the problems, but it doesn't mean the manufacturer isn't responsible for it. How about if a drug company is coming up with a cure for the cold and the only problem is in their test group 10% of the people on it dropped dead when they took it. Think they'd go, "lolz that's just a coincidence, the FDA will pass us for sure, the other 90% are fine." Reply with apples to oranges all you like, it's the same concept.

Personally i noticed a problem when it took 5-6 hours to download a whopping 90MB patch. I haven't had an update that took more than 20min or so for well over a year. Last time it took so long was back during the whole "ddos attacks" bullshit. You can't say it's just congestion either, it's the same amount of ppl downloading and playing as it usually is. If i was to bet on what the cause, i'd go with what someone else already said, that SE implemented some anti-ddos/hacking/detection programs, and it's screwing with some people's connection. I'll admit that's just an assumption like everything else, but it seems to be the simplest answer.
 
Ow...I'm from calgary :(
So are a lot of people here who I considered cool, until I learned they lived there. Then the inherent Vancouver vs. Calgary flame sparked up.

Maybe it's just the dude I work with. Man does he go off about how much he hates Calgary... not that he has any factual evidence supporting all his claims of the people who live there, but it's still funny to listen to.
 
I bet you took all of them, though. The school I went to only paid for CCNA1 and 2 =/
Levels 1 & 2, or CCNA? "CCNA" represents levels 1-4, or it did back then at least. I took 1-8... well, 1-7. Walked out of lv8, PIX Firewalls, with less understanding of them than when I walked into the course.

F_ck PIX and their anal-retentive IOS bullsh!t crap ni663r hating l33tsp34k crack smoking mother horseshoe pliers airplane corndog...
 
Because SE's english customer service staff don't work at the japan SE office? And you're still ignoring the fact that we already explained why you'd only DC from some servers.
They don't need to work there to route through that server server, and it doesn't have to be the person you're talking to that does the actual test. They could get an IP address and relay it to their JP counterpart sitting at SE Japan.
 
Occam's razor - The principle states that the explanation of any phenomenon should make as few assumptions as possible, eliminating, or "shaving off", those that make no difference in the observable predictions of the explanatory hypothesis or theory. This is often paraphrased as "All things being equal, the simplest solution tends to be the best one."

You shouldn't need the cast of CSI to come here and tell you that since these problems occured immediatly following the update, more than likely there is a correlation there. Is it possible that it's a complete coincidence? Sure it's possible, but not probable. It could have been aliens tampering with your connection, or maybe Nixon's ghost, but the simplest deduction would be that it came as a direct result of the update.

I haven't had these problems yet but i've seen alot of others that have. It is not a dat issue for one. I have seen one day playerA cannot enter Port Jeuno without R0'ing and getting DC. The very next day they can, but then it happens in Ru'Lude Gardens. If it were a dat issue, that would not mysteriously fix itself.

You IT guru's can speculate all you want on what the problem is but that's pretty much all it is is speculation. It's possible that something completely unrelated happened the exact time of the update to cause these problems and is only affecting a random percentage of players, regardless of what system they play on, who their provider is, what geographic region they live in, etc, etc, but is that really likely enough to argue it like a pitbull with a piece of meat?

Argueing that since it's only a small percentage and not the whole doesn't really hold water either btw. Have you ever seen when a car manufacturer orders a recall? Usually it's only something like 5% that have the problems, but it doesn't mean the manufacturer isn't responsible for it. How about if a drug company is coming up with a cure for the cold and the only problem is in their test group 10% of the people on it dropped dead when they took it. Think they'd go, "lolz that's just a coincidence, the FDA will pass us for sure, the other 90% are fine." Reply with apples to oranges all you like, it's the same concept.

Personally i noticed a problem when it took 5-6 hours to download a whopping 90MB patch. I haven't had an update that took more than 20min or so for well over a year. Last time it took so long was back during the whole "ddos attacks" bullshit. You can't say it's just congestion either, it's the same amount of ppl downloading and playing as it usually is. If i was to bet on what the cause, i'd go with what someone else already said, that SE implemented some anti-ddos/hacking/detection programs, and it's screwing with some people's connection. I'll admit that's just an assumption like everything else, but it seems to be the simplest answer.
So what would you call your theory? speculation or fact?

All you base your theory on is that it happened to happen together with an update, and thus it have to be SE.
 
They could get an IP address and relay it to their JP counterpart sitting at SE Japan.
...then get shutdown immediately because their JP counterparts yell "JP ONLY! NA TOO WEAK"

There's no hope. :|
 
That you still send packets can't be used as a proof that its not a backbone problem. If you pull your internet cord out, you'd still send. As a matter of fact, you pretty much always send data. Your computer will still attempt to send data even if you don't have a network connection at all.

except that the server gets it
 
They don't need to work there to route through that server server, and it doesn't have to be the person you're talking to that does the actual test. They could get an IP address and relay it to their JP counterpart sitting at SE Japan.
Well, they could, and we can't know if they are doing that or not. I highly doubt the english SE staff (which don't really work for SE) have contact with the JP headquarters though. I believe someone mentioned earlier that they work for sony or something?
 
the checksum transmitted in the packet doesn't actually match what it should be
 
Stouter said:
A handful of zones promptly go to R0 upon entering. The send still works fine, but because of the R0 you dc about 30 seconds after zoning in. Any movement you make is recorded because the send works fine. Again this isn't every zone, it's only a few zones, and it's the exact same zones for several different people.
this is what shows that it isnt a backbone problem, at least for the R0 zones. Packets dont take a different route back from the one they took to get there. They take the fastest route to get there, and then the fastest route back, which is the same route.
If backbone was indeed down somewhere, then any packets you sent would not be able to reach SE, and you wouldn't be able to zone out of the zone.
It also shows that it's not the path that my computer is using to connect to POL that's at fault. My send works just fine, it's what they're sending me that isn't making it this way. I can tracert everything, but it's not going to tell me where they're going through to try and send packets back to me.
 
That you still send packets can't be used as a proof that its not a backbone problem. If you pull your internet cord out, you'd still send. As a matter of fact, you pretty much always send data. Your computer will still attempt to send data even if you don't have a network connection at all.
Yes, but my character has moved the next time that I log in, therefore the stuff that I've sent has made it there.
 
Well, they could, and we can't know if they are doing that or not. I highly doubt the english SE staff (which don't really work for SE) have contact with the JP headquarters though. I believe someone mentioned earlier that they work for sony or something?

I don't know about customer support, but just some intresting facts about the GMs. Alla (and other premire sites) got to tour the SE office in Cali which included the "GM Room/NOC Room".

http://ffxi.allakhazam.com/news/exodus_summit_03-02-2007.html
http://ffxi.allakhazam.com/news/070303-Pikko-Summit.html
 
If Art would answer my question would could tell if it's the route between the hosts that's corrupting the data or the actual encrypted data itself is corrupted which means it must be on SE's end.

His assertion is a VERY important clue, if true.

This might be way off the topic but have you seen a router that got a cut (not unplug) network cable on it? like in a disaster situation such as 911.

It's funny to see the router still thinks there sockets established on that interface and continues to route messages through there and retries for the TCP packets lol

as if the cable is still there lol
 
Last edited:
Back
Top