Se mandaron cualquiera....

[jeancasius]

Originally Posted by ArcticWolf

Les explico como funciona un servidor de un juego genérico (no tiene por qué ser Regnum).

Simple:
El server tiene una copia de los datos en memoria y otra en la base de datos. Como la base de datos es lenta como una tortuga entonces guarda temporalmente todo en memoria, hasta que decide que hay suficiente como para tirárselo a la base de datos. Cuando se cae el server, se borra lo que tenía en la memoria y que todavía no estaba en la base de datos. Es por eso que Surak dice que "no es justo".

Extendido:

Los mensajes llegan a través de un hilo dedicado a la comunicación IO, encargada del envío de datos. Eso se pasa por un parser, que lo tira a un dispatcher (generalmente equipotente para evitar duplicaciones), y luego caen en una queue o cola. Esos datos son leídos por los diversos submotores que componen funcionalidades específicas, como posicionamiento, mobs, recursos, mapa... Pero de algún lado tienen que sacar la información.

Sumado a esto existe algo llamado ORM, que mantiene una abstracción de los datos en la DB como objetos (o structs) en memoria. La idea es que ese ORM es el intermediario entre consultas SQL en crudo y algo más elevado y cercano al lenguaje. Además, las bases de datos profesionales contienen algo llamado transacciones, que permiten que la introducción de datos no cree registros huérfanos o inconsistentes).

¿Pero qué tiene que ver, Xephy? Las bases de datos como MySQL, OracleDB, Informix, PostrgreSQL y muchas más mantienen la seguridad de los datos de esta forma. El problema es que una transacción es segura, pero leeenta. Es por eso que muchas veces los ORMs mantienen los cambios en memoria hasta que cambien lo suficiente y se guarda todo a disco. Eso se llama dirty-triggered flush.

Cuando el servidor colapsa (stack overflow, auto-shutdown, if(ptr){scream(reallyLoud)}), lo más probable es que la capa ORM se muera con parte de los datos sin escribir, o mientras escribía. La base de datos deshace la transacción y se "pierde" información (que en realidad nunca estuvo almacenada, nada más).

me siento como indocumentado hispano cuando lo llevan ante un jez gringo que le habla en otro idioma al suyo y al final mas de lo mismo simplemente que lo pasaron a @~€#~€¬|\@#@.......

[ArcticWolf]

Originally Posted by jeancasius

me siento como indocumentado hispano cuando lo llevan ante un jez gringo que le habla en otro idioma al suyo y al final mas de lo mismo simplemente que lo pasaron a @~€#~€¬|\@#@.......

No espero que lo entiendan, para eso puse la explicación simple. En otras palabras, si no se hacía eso entonces era capaz que resucitabas en medio de la nada, con apenas algo de vida, en el save o sobre el agua.

[Stug]

Originally Posted by ArcticWolf

Les explico como funciona un servidor de un juego genérico (no tiene por qué ser Regnum).

Simple:
El server tiene una copia de los datos en memoria y otra en la base de datos. Como la base de datos es lenta como una tortuga entonces guarda temporalmente todo en memoria, hasta que decide que hay suficiente como para tirárselo a la base de datos. Cuando se cae el server, se borra lo que tenía en la memoria y que todavía no estaba en la base de datos. Es por eso que Surak dice que "no es justo".

Extendido:

Los mensajes llegan a través de un hilo dedicado a la comunicación IO, encargada del envío de datos. Eso se pasa por un parser, que lo tira a un dispatcher (generalmente equipotente para evitar duplicaciones), y luego caen en una queue o cola. Esos datos son leídos por los diversos submotores que componen funcionalidades específicas, como posicionamiento, mobs, recursos, mapa... Pero de algún lado tienen que sacar la información.

Sumado a esto existe algo llamado ORM, que mantiene una abstracción de los datos en la DB como objetos (o structs) en memoria. La idea es que ese ORM es el intermediario entre consultas SQL en crudo y algo más elevado y cercano al lenguaje. Además, las bases de datos profesionales contienen algo llamado transacciones, que permiten que la introducción de datos no cree registros huérfanos o inconsistentes).

¿Pero qué tiene que ver, Xephy? Las bases de datos como MySQL, OracleDB, Informix, PostrgreSQL y muchas más mantienen la seguridad de los datos de esta forma. El problema es que una transacción es segura, pero leeenta. Es por eso que muchas veces los ORMs mantienen los cambios en memoria hasta que cambien lo suficiente y se guarda todo a disco. Eso se llama dirty-triggered flush.

Cuando el servidor colapsa (stack overflow, auto-shutdown, if(ptr){scream(reallyLoud)}), lo más probable es que la capa ORM se muera con parte de los datos sin escribir, o mientras escribía. La base de datos deshace la transacción y se "pierde" información (que en realidad nunca estuvo almacenada, nada más).

WTF????? di que el servidor guarda los datos temporalmente mientras estos no se almacenan y punto, que al caer esos datos caen con el y no se puede devolver a donde estaban los pj.....al leer esto estube al borde de un ataque epileptico

P.D: muy buena explicacion. Aunque algun termino de esos no fuera verdad a mi me engañarias muy bien.

[Carpi]

Originally Posted by ArcticWolf

Les explico como funciona un servidor de un juego genérico (no tiene por qué ser Regnum).

Simple:
El server tiene una copia de los datos en memoria y otra en la base de datos. Como la base de datos es lenta como una tortuga entonces guarda temporalmente todo en memoria, hasta que decide que hay suficiente como para tirárselo a la base de datos. Cuando se cae el server, se borra lo que tenía en la memoria y que todavía no estaba en la base de datos. Es por eso que Surak dice que "no es justo".

Gracias!

Originally Posted by joda

Segun vos el server se cayo cuando quedaban 20 minutos?

Toma una foto, segundos despues de darnos cuenta que se cayo el server.

http://img269.imageshack.us/img269/1...9070800351.jpg

Yo nombré 20 minutos asique calculo que será para mi.

No era mi intención que se entendiera eso. Si bien después de dar el ejemplo (usando 20 minutos como cifra) pongo "eso es lo que vi hoy" no era por el tiempo sino por donde reaparecen los personajes.
Si te fijas el tiempo cuando se cae el server y cuando vuelve es el mismo en mi ejemplo.

Era solo eso, un ejemplo cualquiera sobre una situación que se puede dar en cualquier muralla.

Saludos y perdón de nuevo si se mal entendió.

[ljrossi]

Si stug es asi, lo ultimos momentos antes de la caida del server desapacen....

Imaginate si acabas de recibir un drop por ejemplo, lo perderias....

[Gotten]

Yo apareci las dos veces a 5 metros de donde habia crasheado y los que estaban conmigo aparecian en la otra punta del mapa. Da igual, nunca se puede jugar como uno quisiera, siempre hay fallas, o lag exagerado, o caidas del server, pequeños bugueritos......Que mas da.

[lord_dvl]

Originally Posted by Albus_Camus

No, surak nos avisó por estandarte que la puerta se iba a cerrar antes. No nos confiamos de nada, simplemente apareciamos todos en diferentes lugares y teniamos que juntar.

Le hago un Quote a Albus porque es mas o menos lo que quiero decir. No estuve en esta pero estuve en otras invasiones y paso algo parecido...

El tema no es cuanto tiempo falta o no, sino que el problema radica en que apareces en cualquier lado y ademas te restauran el tiempo como debe ser, o sea, no llegas nunca despues de la caida y por ende no se puede invadir. También pasó en invasiones de ignis a syrtis y de alsius a ignis y todas las posibilidades que existan, el punto es que cuando volves, volves en cualquier lado.

Estas cosas van a seguir pasando y aunque sea una boludes, esta bueno que pase ya que con esto NGD (y espero que lo haga ) puede recopilar datos para mejorar el codigo. Una cosa es probarlo en AMUN con 100 y otra probarlo en RA con 1500.

Esperemos que se llegue a un termino medio en las proximas versiones.

Nos vemos.

PD: Buena explicación Xeph, como siempre.

[Angel-Raptor]

Originally Posted by EXZURY

Algunos prefirieron matar a Daen que defender la puerta por eso la rompieron ,, jajaja lo que mas me da gracia es que los ignitas que peleaban con Daen cuando se cayo el sever daen desaparecio jaja eso se meresen por no defender puerta ( si odieme que les costo esperar que terminara la vunerabilidad para matar daen? la codicia es mala en eseso) saludos........

Yo fui uno de los que fue a matar a Daen en vez de defender, ¿Por Que?
El lag era TREMEDO en puerta, ¿a que iba a ir a una pta puerta en la que ni moverme puedo? hacia mas estando parado con Daen que irme a puerta a no hacer nada con "Connection Problem" asi que ni castear un aura se podía.
Saludios =)