Cross Data Center Party Finders

[SorrowsEnd]

It would be great if it were possible to add cross data center party finders. I.E myself on Aether being able to play with someone on Chaos. Being able to play with friends on any data center would be amazing and would make the game a whole lot better. It'll be a technical challenge but if possible I think it could make FF 14 a much better game.

[KisaiTenshi]

It would be great if it were possible to add cross data center party finders. I.E myself on Aether being able to play with someone on Chaos. Being able to play with friends on any data center would be amazing and would make the game a whole lot better. It'll be a technical challenge but if possible I think it could make FF 14 a much better game.

Won't happen. That's why they are in different data centers. When the servers are in the same data center, they go through the same switching fabric, and thus there is negligible latency between the machines. When they are in different data centers, they have to go across the routers, so synchronization becomes impossible, especially if players are in Japan and Europe want to play with players in NA. Which direction is your data going? Circumnavigate in which direction?

The data centers in NA might have "next door" ip addresses, but that doesn't mean they are in the same building, or even in the same city. We only know where they are due to the trace logs.

[NephthysVasudan]

Previous Reply is not entirely correct...but valid none the less.

It CAN happen....but it wont.

Each "DC" is in a different physical location....and data centers are not "Everywhere" (I work at one...not an SE one mind you...but at a Datacenter none the less)

The reason you don't see "Cross DC" parties is the connection required would be rather intense in terms of VPN/Proxy/Tunneling.

People make the mistake of thinking in terms of them and a couple people....when they need to multiply that in the thousands.

Add to that any DC's that are "Out of country" - each country has different bandwidth challenges and "allowances" in terms of cost and what they are allowed to push/pull.

It's costly...is the point.

It grows exponentially when you factor in people who use it.

Bottom line - can it be done? yes
Will it get done? Not unless SE decides to dump a ton of money on it....not likely to happen in the immediate time frame...let alone medium. Even if it could..you'd run into very weird latency issues.

[SorrowsEnd]

I'm pretty sure WoW has a feature like this so I don't see any reason as to why it can't be done in like say 5.0. It's not that costly but it could be done given SE gets a bigger budget for 5.0 like they did come 4.0.

[NephthysVasudan]

I'm pretty sure WoW has a feature like this so I don't see any reason as to why it can't be done in like say 5.0. It's not that costly but it could be done given SE gets a bigger budget for 5.0 like they did come 4.0.

Blizzard is not SE....and its certainly not CCP (EVE Online).

And Last i checked...Blizzard has their systems broken down by region. EVE Online (CCP) is a single shard universe and that means everyone is on one server (Not sure if the are still doing their Chinese mirror experiment however).

Bottom line - FFXIV is not the same topology/layout/tech.

So you can't say "will this game can do it so why not this one" because its not the same..not by a long shot.
Architecture/code/methodology are entirely different.

If they where the same - they'd be not restricted by patents etc.
Just cause it looks simple - doesn't mean it is.

[KisaiTenshi]

I'm pretty sure WoW has a feature like this so I don't see any reason as to why it can't be done in like say 5.0. It's not that costly but it could be done given SE gets a bigger budget for 5.0 like they did come 4.0.

Wow does Cross-realm-zoning. Not cross-data center. WoW doesn't connect players that are in different time zones either. Actually after reading their patch notes it's almost like the CRZ is a lot more brittle than we're lead to believe.

https://worldofwarcraft.com/en-us/news/7207170

General
Cross-realm zones no longer bring together players who are more than 3 timezones apart.

When Tol Barad and Wintergrasp battles commence, cross-realm zoning should now cease for the duration, and resume after the end of the battle.

Cross-realm zones no longer behave erratically when a party changes leader.

Also they don't match PvE and PvP servers or RP and non RP servers.
WoW's "realms" = FFXIV's servers.
WoW's data centers are in LA and Chicago

Previous Reply is not entirely correct...but valid none the less.

If I write a long post, nobody reads it, and people do a "not all..." splaination of some generalization that was not important. If I write a short post to just cover the important part, someone else will inevitably try to explain something that didn't need explaining.

I work with servers and machines in different data centers all the time. There is no way to explain to mundanes the intricacies of how networking works. A tech fight on the forum always results in people who don't actually know how things work trying to explain it to people who actually do this job, wrote the tools, or even have the source code to tools they're trying to explain to them.

SE clearly operates the NA servers out of LA because that is what makes sense to them at their LA HQ instead of out of Montreal where they were operated by their Eidos data center. This illustrates it perfectly:

https://www.submarinecablemap.com/#/...le-network-jus


Based on the traceroutes,
Aether is 204.2.229.9
Primal is 204.2.229.10

Chaos is 195.82.50.9

Mana 124.150.157.156
Gaia is 124.150.157.157
Elemental 124.150.157.158

So a mundane person goes "oh look, those IP's are right beside each other, they must physically be beside each other"

When that is just the end-point router. Those routers could be in the same building, or they could be mapped into a virtual network address space.

Mapping Aether and Chaos to for players to play together would require SE to quite literately run the cross-realm instances off some back-end infrastructure that we are not actually aware of that is still hosted by one of the data centers, so those who are not in that data center will get some serious lag, as if they had connected to the NA data center in the first place. Only their end sees them still connected to their server, the back-end costs are being borne by SE, having to send the data back over the internet to synchronize with the other server, so it costs them twice as much to operate.

Here's a more tech-savvy explanation:

Router: Sacramento, CA - US

Tracing the route to 204.2.229.9

1 *
xe-0-1-0-1-1.r00.scrmca02.us.ce.gin.ntt.net (129.250.195.46) 0 msec 0 msec
2 *
204.2.229.234 0 msec 0 msec

Tracing the route to 195.82.50.9

1 ae-6.r01.snjsca04.us.bb.gin.ntt.net (129.250.7.56) 4 msec 3 msec 3 msec
2 sjo-b21-link.telia.net (62.115.12.52) 3 msec 3 msec 3 msec
3 nyk-bb3-link.telia.net (213.155.130.128) 81 msec
nyk-bb4-link.telia.net (62.115.119.228) 82 msec
ash-bb3-link.telia.net (80.91.252.221) 74 msec
4 prs-bb3-link.telia.net (80.91.251.242) 163 msec
nyk-b5-link.telia.net (62.115.115.1) [MPLS: Label 5949 Exp 0] 81 msec
prs-bb4-link.telia.net (80.91.251.101) 154 msec
5 ffm-bb4-link.telia.net (62.115.122.139) 164 msec
ffm-bb3-link.telia.net (62.115.123.12) 171 msec 174 msec
6 ffm-b1-link.telia.net (62.115.137.169) 160 msec
ffm-b1-link.telia.net (62.115.121.11) 158 msec
ffm-b1-link.telia.net (62.115.121.1) 176 msec
7 kddi-ic-319844-ffm-b1.c.telia.net (62.115.32.106) 164 msec 164 msec 174 msec
8 * * *
9 * * *

So there is at least 164ms from Sacramento NTT's router. Take note that WoW/Overwatch players complain about Telia.net.

Now let's ping from their side. It appears the last hop is Frankfurt Germany, so let's try that.

Network: AS1299 - Telia Carrier
Router: Frankfurt (ffm-b1)
Command: traceroute 195.82.50.9 as-number-lookup

traceroute to 195.82.50.9 (195.82.50.9), 30 hops max, 52 byte packets
1 kddi-ic-319844-ffm-b1.c.telia.net (62.115.32.106) 6.903 ms 10.091 ms 0.552 ms
2 * * *
3 * * *

Network: AS1299 - Telia Carrier
Router: Frankfurt (ffm-b1)
Command: traceroute 204.2.229.9 as-number-lookup

traceroute to 204.2.229.9 (204.2.229.9), 30 hops max, 52 byte packets
1 ffm-bb4-link.telia.net (62.115.116.159) 1.474 ms 1.544 ms 0.964 ms
2 ffm-b4-link.telia.net (62.115.120.6) 0.885 ms 1.641 ms 0.854 ms
3 ntt-ic-323130-ffm-b4.c.telia.net (62.115.147.65) 1.092 ms 1.194 ms 1.376 ms
4 ae-24.r24.frnkge08.de.bb.gin.ntt.net (129.250.3.217) [AS 2914] 1.209 ms 2.809 ms 2.145 ms
5 ae-5.r24.londen12.uk.bb.gin.ntt.net (129.250.3.12) [AS 2914] 14.162 ms 17.167 ms 15.243 ms
6 ae-5.r24.nycmny01.us.bb.gin.ntt.net (129.250.2.18) [AS 2914] 83.096 ms 90.859 ms 81.186 ms
7 ae-4.r22.sttlwa01.us.bb.gin.ntt.net (129.250.4.13) [AS 2914] 154.194 ms 148.285 ms 148.635 ms
8 ae-0.r23.sttlwa01.us.bb.gin.ntt.net (129.250.6.30) [AS 2914] 151.471 ms 147.519 ms 151.867 ms
9 ae-3.r23.snjsca04.us.bb.gin.ntt.net (129.250.3.124) [AS 2914] 167.793 ms 171.093 ms 166.894 ms
10 ae-41.r02.snjsca04.us.bb.gin.ntt.net (129.250.6.119) [AS 2914] 168.769 ms ae-45.r01.snjsca04.us.bb.gin.ntt.net (129.250.3.175) [AS 2914] 157.264 ms ae-41.r02.snjsca04.us.bb.gin.ntt.net (129.250.6.119) [AS 2914] 162.350 ms
11 ae-3.r00.scrmca02.us.bb.gin.ntt.net (129.250.7.11) [AS 2914] 162.666 ms 170.922 ms 168.723 ms
12 xe-0-1-0-1-1.r00.scrmca02.us.ce.gin.ntt.net (129.250.195.46) [AS 2914] 169.103 ms 176.595 ms 167.467 ms
13 204.2.229.234 (204.2.229.234) [AS 2914] 168.645 ms * 174.753 ms
14 * * *
15 * * *

So we see 164-175ms in both directions. That is just under the Nagle algorithm's 200ms. Since movement is every 500ms and everything else the server does is 3000ms, this at the minimum a perfect connection and zero overhead, someone ends up with 175 lag, multiplied by the number of players.

So in a 4-player duty, let's say two are in Aether and two are in Chaos, and the actual instance is running in Aether, that means that every command the EU players do, is delayed by 175ms at the minimum if they live in Frankfurt Germany, while the NA players, assuming they live anywhere between Vancouver and San Diego on the West coast will get somewhere between 60ms and 6ms.

So let's now assume a worst-case scenario where Aether hosts a 24-player instance, and one alliance party is from Japan, one from NA and one from EU, and all the players in EU are in the UK, while the players in NA are in NYC.

It looks like this:
22ms from London to Frankfurt (Chaos), So that just sneaks under nagle when combined with the 175m EU trip.
88ms from NYC to Sacramento (Aether)
0ms from Tokyo to Tokyo, 155ms from Tokyo to Sacramento

So the framestepping would look like this

0ms start
88ms, received NYC players movement packets
155ms received JP players movement packets
176ms, received NYC players movement packets
197ms received UK players movement packets
200ms ACK
288ms received NYC players movement packets
355ms received JP players movement packets
376ms, received NYC players movement packets
397ms received UK players movement packets
400ms ACK
488ms received NYC players movement packets
500ms transmitted movement positions to NYC,JP and UK
555ms received JP players movement packets
576ms, received NYC players movement packets
597ms received UK players movement packets
600ms ACK
688ms received NYC players movement packets
755ms received JP players movement packets
776ms, received NYC players movement packets
797ms received UK players movement packets
800ms ACK
888ms received NYC players movement packets
955ms received JP players movement packets
976ms, received NYC players movement packets
997ms received UK players movement packets
1000ms ACK, transmitted movement positions to NYC,JP and UK

You'll note that for the sake of making things look sane, I put ACK on 200ms boundaries with the assumption that Nagle is on. It results in the NYC players getting only one extra command ACK.

If Nagle is off, ACK occurs immediately and would result in something like this:

0ms start
88ms, received NYC players movement packets,ACK
155ms, received JP players movement packets,ACK
176ms, received NYC players movement packets,ACK
197ms, received UK players movement packets,ACK
264ms, received NYC players movement packets,ACK
310ms, received JP players movement packets,ACK
352ms, received NYC players movement packets,ACK
394ms, received UK players movement packets,ACK
440ms, received NYC players movement packets,ACK
465ms, received JP players movement packets,ACK
500ms, transmitted movement positions to NYC,JP and UK

528ms, received NYC players movement packets,ACK
591ms ,received UK players movement packets,ACK
616ms, received NYC players movement packets,ACK
620ms, received JP players movement packets,ACK
704ms, received NYC players movement packets,ACK
775ms, received JP players movement packets,ACK
788ms, received UK players movement packets,ACK
792ms, received NYC players movement packets,ACK
880ms, received NYC players movement packets,ACK
930ms, received JP players movement packets,ACK
968ms, received NYC players movement packets,ACK
985ms, received UK players movement packets,ACK

1000ms, transmitted movement positions to NYC,JP and UK
1056ms, received NYC players movement packets,ACK
1085ms, received JP players movement packets,ACK
1182ms, received UK players movement packets,ACK

So what's wrong with above? The NYC players have essentially double the movement resolution as the Japan and UK players. The JP and EU players will always be behind. Take note of the 500ms transmission ACK, the the NYC players get to send 5 movement commands in the same time space the Japan players get to send 3 and the UK players only get 2. After the first movement update, then the NYC players get 6 movement commands, the JP players get 3, and the UK get 3.

Networks don't operate on exact numbers like this, and also congestion can result in packets being delayed. So if there are 24 players in a cross-data center zone, and the EU international connection drops for 500ms, everyone in that zone on the EU connection drops immediately, as there's no way to re-syncronize. That results in the NYC players being kicked out as well since the instance would need to be restarted.

So to summarize, SE would likely never do this because aside from costs, it would require changing the topology of their game network and how the game servers communicate in a way that it would never be fair to the players who aren't in the data center that the instance is running from in the first place.

[Paladinleeds]

From what Kisai said, I'm wondering if perhaps then a new EU datacentre is needed. Plus seeing how the cross-realm switching works in WoW and how it has apparently fallen flat on its face.

Though, I wonder if at least for the HW zones (as say a test bed), could Square Enix add CRZ to it? Only within the same datacentre of course. So only Chaos-Chaos players (for example, I use this as I'm on Chaos). I think that'd be more reasonable and could help bring places more to life. It depends how item trading works when via CRZ in WoW, as to how FFXIV would tackle it. Expand to other zones later on. Maybe even at some point get housing under their belt to visit other members/FCs houses on other servers?

But yeah, I have zero desire to have cross datacentre party finders. I've been advised to raid on Aether/Primal (whichever the good raiding DC is), I refuse to because it means ~200ms ping instead of ~20ms. I would rather have a ridiculously hard time finding a raid group than put up with 200ms ping. Adding this would just have almost everyone go for cross-DC PF's because more peeps, leaving people like me out in the cold.

[Rufalus]

This is what S-E describe as one of the hardest things they could do, even to just have x-dc comms like linkshells.

Maybe a more feasible solution could be buying guest passes which allow you to temporarily transfer your character to a different data center / world, with restrictions while you are there like not being able to use their marketboard, initiate trades or buy housing plots. Then you can return to your home world when you're done playing with them.