POL News: All Worlds Maintenance

Uzor said:
I've had those problems before. I know what its like. Hell, the majority of the Swedish population had it a few months back, but no one else had it. I know exactly what its like, 'cause I couldn't even log in to the game for several days, and when I finally managed to log on, I couldn't stay connected for more then 1 hour at a time, and would then take another 20 min to log on.

I called SE, they said everything was working fine. I then called my ISP, they said everything was working fine.

I didn't run around screaming "OMG! SE'S CUSTOMER SERVICE SUCKS BECAUSE THEY REFUSE TO FIX MY PROBLEM!". Everyone in Sweden had that problem. We've had this occur a total of 3 times for months at a time. Don't give me that "If you had this problem you would change your oppinion" attitude. Its not SE's fault. There's nothing they ca ndo about it. You need to either call your ISP, or wait untill its fixed by itself. There's no use running around saying how much SE sucks.
Click to expand...
Maybe you don't understand what the problem is. Someone didn't simply cut the string between the two cups that we use for our phone lines.

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.

I've had the same problem with single zones in the past and made at least 3 GM calls over it only to be told "if you dc after entering that zone, don't enter it." That's nice unless you want to do dynamis, or limbus, or something like that. In the past the problem was never more than one zone, it was never such a large number of people, and it never lasted more than a real life day.

Before the update those zones worked fine, after the update they were broke for several people. Do you really believe that it wasn't the update that caused the problem?
 
Everlasting said:
If it is some type of traffic shaping it was implemented at the exact same time that FFXI was updated, and the odds are sharply against that.
Click to expand...

Agree :)

SE made a "number" of updates on th 8th JST and the 9, it's a question to me that:

1) which update "would" have caused this...
2) is it really one of the update that caused RO or it's the backbone?

I am not sure lol

That's why it states in ITIL best practice for a failed change to roll back, or that wouldn't work in MMO? maybe SE don't know "which" update(s) they made would've caused the US/EU side of the world to have RO

This is too hard.... lol i'm gonna play around with publikc proxy if i have time tonight lol
 
Everlasting said:
The "research" you did is impossible as I explained before. Either you're not telling the whole story or you're lying, I still don't understand why you won't address my point if you feel you're so right and have done this "research". If you did what you said you did then answering my question is very simple and will help everyone get one step closer to determining what the actual problem is, why aren't you?

You make multiple updates at the same time to reduce downtime. It's foolish to have two separate downtimes when you can do everything during one. I'm not sure what makes you think it would take an entire day to update the encryption.

Here's a nifty idea for you: What if only say 20 of their 100 servers are somehow sending out bad data? I've worked with load balanced web servers where one server has the new page and the other one still has the old page. Guess what happened? Only *some* people have the problem yet it was our problem!

Uzor, MAC address has nothing to do with routing, they are very far removed from each other as far as networking is concered.

What's making this frustrating is both you and Uzor have incomplete or incorrect knowledge and are aruging based on that. You continue to make points based off incorrect assumptions and don't address my legitimate questions.
Click to expand...
Not routing, but it have everythign to do wit hnetworking. The gateway have a unique MAC address, which is used to identify each "node" on the network. If you want to talk about layers, the MAC layer interfaces directly with the network. If a MAC address on a smaller network is changed, the gateways need to find a new route to the computer in question, as it saves networking information with MAC addresses. I can only imagine it works the same way on a larget network.
 
acts said:
thanks, i put a lot of effort into it on mspaint, but nobody seems to notice or care :(
Click to expand...


I care acts. I think your post was pretty calm, informative, and most importantly not condescending. I think the deal in this thread is, people experiencing the problem just don't like to be painted with a label of stupidity, whininess, or incompetence. That's the big difference between your helpful post and some of these others.

Thank you for that.
 
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.
Click to expand...
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.
 
Stouter said:
Maybe you don't understand what the problem is. Someone didn't simply cut the string between the two cups that we use for our phone lines.

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.

I've had the same problem with single zones in the past and made at least 3 GM calls over it only to be told "if you dc after entering that zone, don't enter it." That's nice unless you want to do dynamis, or limbus, or something like that. In the past the problem was never more than one zone, it was never such a large number of people, and it never lasted more than a real life day.

Before the update those zones worked fine, after the update they were broke for several people. Do you really believe that it wasn't the update that caused the problem?
Click to expand...
if you'd have read the thread you'd see that we already explained why that is happening. Someone even made a pretty picture.
 
Marajade said:
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.
Click to expand...

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.
 
Uzor said:
The gateway have a unique MAC address, which is used to identify each "node" on the network.
Click to expand...
MACs are largely useless until you get into DHCP reservations. The Internet and all it's protocols work on IP only. MACs are unfortunately dynamic today, even home users can change their damn MAC (which seems like a total waste... originally they were hard-coded so it was simpler to work backwards, easier to track specific problematic nodes, etc).

Uzor said:
If a MAC address on a smaller network is changed, the gateways need to find a new route to the computer in question, as it saves networking information with MAC addresses. I can only imagine it works the same way on a larget network.
Click to expand...
Gateways only care about IPs, more specifically subnets. It saves nothing with MACs. Indirectly, in some cases, yes changing a MAC can alter an IP - but any appliance that holds a candle of importance has a static IP, so changing it's MAC will do nothing (excluding some port-blocking protocols such as STP, I believe).
 
Uzor said:
Great, then we can conclude that the problem is somewhere between your house and SE.

Since everyone don't have the same problems, we can conclude that the problem is somewhere between your house and somewhere before SE's building.

Since you say you have the same problem on all of your consoles, we can conclude the problem is somewhere in the backbone.

Thus, people with the problem need to perform a tracert to find out where the backbone is.
Click to expand...
No this doesn't mean that it's something in the middle at fault. It could be that the update doesn't work with specific hardware, or drivers for hardware.
 
CmdrFly said:
MACs are largely useless until you get into DHCP reservations. The Internet and all it's protocols work on IP only. MACs are unfortunately dynamic today, even home users can change their damn MAC (which seems like a total waste... originally they were hard-coded so it was simpler to work backwards, easier to track specific problematic nodes, etc).


Gateways only care about IPs, more specifically subnets. It saves nothing with MACs. Indirectly, in some cases, yes changing a MAC can alter an IP - but any appliance that holds a candle of importance has a static IP, so changing it's MAC will do nothing (excluding some port-blocking protocols such as STP, I believe).
Click to expand...

Well, iunno. You might be right. That's the way I was taught, anyway. I suppose Cisco's course were rather outdated 4 years ago.
 
Last edited:
Uzor said:
That's the point. If its a backbone problem, there's nothing SE can do if they don't know where it is. And finding it themselves would take a lot longer then their playerbase helping them out.
Click to expand...
They have a much larger IT staff than I do, couldn't they simply do the tracert for everyone that calls up technical support with a problem? It does work both ways.
 
Stouter said:
They have a much larger IT staff than I do, couldn't they simply do the tracert for everyone that calls up technical support with a problem? It does work both ways.
Click to expand...

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.
 
Stouter said:
They have a much larger IT staff than I do, couldn't they simply do the tracert for everyone that calls up technical support with a problem? It does work both ways.
Click to expand...

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.
 
Art buddy I didn't want to play this card but I have to now: I've been a UNIX admin for almost 10 years now, senior level for 7. I don't specialize in networking but I've had to touch it very often, so I know it well. I've passed both HP's and Sun's networking certifications. I have a very good understanding of how networking works, and encryption too for that matter (Sun Security Admin certified baby!), I've worked with it frequently.

If you really think I somehow just pulled that encryption and networking stuff outta my ass, I didn't. It's been my life for years now.

I'm going to offer up an opinion for you. The moon is made of moogles. If I told you this, wouldn't you say to me "What the hell are you talking about? I know the moon isn't made of moogles and here's why." Or possibly "Really hmmm, explain that to me Ever." and I would go off with crazy facts and ideas. You made a HUGE assertion, then offered nothing to back it up. I'm calling you on it and now you've resorted to avoiding my questions and not being able to elaborate at all. You said the moon was made of moogles and when someone asks you to elaborate you clam up. If you have the balls to state your opinion have the brains to backup your claims.

I don't see a reason of going out of my way how it's not impossible to recognize and work with some corrupted encoded code.
Click to expand...

Then you don't understand the fundamentals of encryption and are obviously making things up. I'll send you a $20 Amazon gift cert if you can show me how to decrypt a corrupt encrypted file. Prove old Ever wrong, prove yourself right and earn some $ at the same time.

And why haven't you answered my question about which part was actually corrupted? It would essentially end this debate for me and be a HUGE help to SE but for reasons still unknown you won't. Naw I'm kidding, we all know why you won't.

It's your choice to quit defending your opinion at any time, but by stating it you just might have to back it up.
 
Uzor said:
Well, iunno. You might be right. That's the way I was taught, anyway. I suppose Cisco's course were rather outdated 4 years ago.
Click to expand...
If you took them four years ago, we should technically be on the same page. I completed my CCNP courses in June 2003.
 
Uzor said:
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.
Click to expand...

I would very much assume so... it's like Dell/IBM/BEA outsource a lot of call center supports to India...
 
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. ;)
 
Ubuntu said:
I would very much assume so... it's like Dell/IBM/BEA outsource a lot of call center supports to India...
Click to expand...
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.
 
You must log in or register to reply here.
Back
Top