Can we have an update on the situation.

[Deadvinta]

I see so many posts about "working on getting the servers back up." You people realize this isn't a crash, right? They actively shut down the servers.

[Mattis]

For Mattis....

I can't go into details here as it would take pages but the cost impact is massive. Your single stream of network data is fine to route across the internet from your DSL connection, but we are talking 10,000s of simultaneous users data that must arrive in a set order for it to form a stateful position in time. You will definately need something more stable and you will need redundency as you would be surprised how often large loops are down and automatic rerouting picks up the slack.

Your belief that this capability is widespread is flawed, many companies have transaction shipping offsite but not in realtime situations as the flood of data is a never ending torrent. Without mentioning names a very large national bank has twin server houses less than 100 miles apart but on seperate power grids and this is considered sufficient protection.

Like I said the details are tedious, this is what I do and it is not as straightforward as you make out.

OK fair enough, I am more software then hardware anyways so I concede that I may very well be wrong. Just didn't make sense that 1 x 1 = 100% and 2 X 1 = 1000% +. I still think that I could write software with compression to transfer all that data rather quickly and automatically reroute dropped packets before the data is committed on the backup server. Also it doesn't truly have to be real time, the production server would be down while the transfers were taking place.
But either way I think I could do it I have never done it. If you do this for a living and you say it is done that way
like I said I have to take your word for it. If it was as easy as I think it would be then companies would be doing it already so that pretty much says im wrong right there.

Thanks for clearing that up.

[Mattis]

I see so many posts about "working on getting the servers back up." You people realize this isn't a crash, right? They actively shut down the servers.

Um yeah, you just said it yourself they shut them DOWN. Asking for them to work to get them back UP makes perfect sense still.

By working to get them back up just means finding alternative power rather then fixing the software or hardware.

[Ter]

No problem realtime is a pain and theres no doubt, by the time you have tried to compress or manipulate the packets you have a backlog and as it keeps coming it just gets bigger and bigger. Dropped packets are also a major issue as you can't afford to resync all the other arriving traffic while waiting for a resend. Point to point is the only real solution that has ever worked and that cost a lot.....

[RAIST]

@Ter
/agreed

It's not just a simple single server to single server transaction. It would be a room full of servers handling 500 2 way connections (or more) at once in real-time, some servers synching with other servers at the same location, then trying to replicate all that to a room full of servers at another location. Replicating a cluster of say Exchange email servers or a website taking tax payments on line in no way compares to this level of traffic. They would have to dedicate a fiber line just for this communication, as well as additional staff, deal with different labor/DRM/copyright/etc. laws--in short, it would be like a whole additional division over there. If they did in fact research this when setting things up, they likely have deemed it not worth the cost.

Raist

[Ter]

Raist you have hit the nail on the head. So many companies that look into the problem soon catch on that the costs make their product uncompetitve and it therefore really isnt an option.

[krusnik213]

I was just wondering about something my friend said about SE maybe moving the servers to california if it took longer than a week to get them back up and running. Is there possibly any truth to this? Also i hope the people of japan all the best

[Selzak]

It's so irritating to see people speak so loudly about things that they haven't the first clue about.

[Mattis]

No problem realtime is a pain and theres no doubt, by the time you have tried to compress or manipulate the packets you have a backlog and as it keeps coming it just gets bigger and bigger. Dropped packets are also a major issue as you can't afford to resync all the other arriving traffic while waiting for a resend. Point to point is the only real solution that has ever worked and that cost a lot.....

OK like i said i digress here, but just out of curiosity let me run this by you if you will.

Both server are off, there is no data whatsoever coming onto the real server (this is a must and no doubt it would be very expensive to do it in real real-time not to mention risky)

It seems to me that you take the time stamp from the last server transfer and compile one big script to redistribute the new data to the backup server. Compress that so It doesn't take a week to transfer it and transmit that to the backup server. Now basically the big script is like one big torrent. It doesn't really matter if you have dropped packets the information coming behind it can keep coming. After transfer is complete the script self-checks itself and re-downloads missing packets as needed. Only after the script is 100 percent in tact does it uncompress and execute and only after getting conformation that the script executed without error is the production server put back on line to receive more data.

[Ilax]

It's so irritating to see people speak so loudly about things that they haven't the first clue about.

yes it is... welcome to public forum.