Jump to content

Server Status (outdated)


Recommended Posts

Yeah I lost connection in the middle of mining :P Couldn't warp or dock or loot or anything and now server status is back to "STARTING" so I'm sure the server is just having a hiccup, should be back to normal soon :)




EDIT
Maybe....? Edited by rockrat
Link to comment
Share on other sites

I work 2nd shift, and soon to go to 3rd, I would rather it happen at a different time :)
Actually I wish I had the ability to restart, but with all the new problems, it is surley not going to speed things up - wish I had better news.
Link to comment
Share on other sites

yep, it's broke. And the reason they just don't restart it every time it goes down, as I understand it, is they need to look at it in it's broken state, to see what is wrong so it can be fixed.

Punching restart reflexively isn't the answer, much as we would all like to play :)
  • Upvote 1
Link to comment
Share on other sites

[quote name='TooTall' timestamp='1326884312' post='51741']
yep, it's broke. And the reason they just don't restart it every time it goes down, as I understand it, is they need to look at it in it's broken state, to see what is wrong so it can be fixed.

Punching restart reflexively isn't the answer, much as we would all like to play ;)
[/quote]

Its even WAY more complicated.

A multiplayer game has many many mechanism, they are all threaded which makes it even harder (mutex, locking, deadlocks etc).
So whenever a server goes down, you cant say what was causing the crash.

It was something one player did or (worser) some did in conjunction, where "conjunction" could also be, that one player was looting a mob while another opened another corp.
This requires some locks and even crosslocks (Corpse to loot is goinf to be changed (mem-write), player objects are changed, inventory are changed, cash balance changed, groupobjects etc etc etc).
There are MANY things going on.

A single write, a lock not released, a single variable changed....that all can cause an immediatly server crash.
Threaded mutex coding is one of the worsest bitches.... :)
If you do that without a wrapper, you can count on two fingers when you are "raedy to redo the whole code". EnB source has a wrapper class for that.

So the only chance you got is, to have the server running all time in debug mode on a debugger. This is causing a hug performance hit and the server lags noticeable.
A alternative way for the devs is, to have certain "key log entries". So the server will write logs all time, esp. in "critical" functions.

The dev can check logs after crash and see, what was the last the server was doing.
Unfortunatly this wont help only rarely cuz the crash is a result of more then one single function, its a result of more functions executed the same time.
Each function for itself is clean and works fine - just the combination of diff. tasks similar running is causing the crash - very hard to figure out!

This is why a play-server like this is very very important to the devs, because ONLY(!) player in higher numbers are able to stress the server in the needed way to find such problems.
A single dev or 3-5 devs "testing" the server are simply NEVER EVER able to reproduce such problems.

This is why many games released by the studios have so many bugs still after release, because NOW(!) the big numbers hit and this is the first time, every little tiny bug reveals for the first time...
Beta Testing is helping but not completely solving in advance.


This time, the login server crashed.
This COULD be due to "normal" code problems, but more likely its some1 fiddeling around with it (again) in a way, that isnt supposed to be (aka security)....
HANG 'EM HIGH!!! :P


Yes, i am (also) a software coder by profession - No, i don't join :lol:


I am running a little software house, we are coding individual industrie software for our customers.
I have some time to play at my daytime (GMT+1) "on the other screen", but involving in an emulator is a very time-intensive task.
I was helping another emu-project in the past, so i know what huge task it is - no1 should underestimate it.

Its even not good to have too many coders - like we say: Too many cooks spoil the broth.

The current devs know (hopefully :lol: ) very good what they do and the ongoing process of the emu is proving it.
Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...