Matteo 'Ndwr' Russo

...because there are no days without revolutions.
* Notizie* Lavori* Progetti   * Construct   * Tess   * Opengroups      * CCP      * SCP   * VES      * SS      * ES   * AS   * DMS      * TS   * TPL   * RVD   * CL      * libCGL      * libCSL      * libMixer      * libCTL      * libCIL      * libCVL   * RCGV   * RU1* Pensieri e Articoli* Macchine* Contatti

 

Radioattività ambientale
Zona: Venezia, Italia
Tipo: Radiazioni ionizzanti β/γ

 0.00%

Corrente: 0 μSv/h
Media annuale: 0.00 μSv/h
Accumulo annuale: 0.000 mSv

* Spazio   * Sistemi di lancio      * I razzi sonda      * Delta II      * Soyuz-U      * Soyuz      * Soyuz-FG      * Soyuz-2   * ACE      * Strumentazione         * MAG         * SWEPAM         * SIS         * EPAM      * Locazione   * SOHO      * Antenne HGA/LGA      * Strumentazione         * EIT            * CCD         * LASCO         * MDI   * STEREO      * Strumentazione   * AMS-01   * AMS-02      * Strumentazione      * Materia oscura   * EOS AM-1      * Strumentazione         * MODIS
 
http://ndwr.net --> Progetti --> VES
 

VES, Virtual Environment System

2004 ~ Oggi
Dipendenze: CL


Introduzione

VES, acronimo di Virtual Environment System, possiamo descriverlo come una grande macchina dinamica capace di formare una rete di servizi ad estensione infinita, contenuti all'interno di un ambiente virtuale tramite il quale gli utenti possono interagire.


L'inizio dello sviluppo

L'idea iniziale consisteva in un semplice server che gestiva tutte le fasi utili ad autenticare un utente e permettere allo stesso l'interazione con tutti gli altri utenti connessi.
Modificando il client di un noto MMORPG utilizzato per le prove e facendo in modo che si connettesse a VES diventava possibile effettuare le varie operazioni di autenticazione e iniziare ad interagire in modo visivo.
Le prime versioni funzionanti davano ottimi risultati. Creando di volta in volta codici sempre più ottimizzati il sistema di gioco prendeva lentamente vita.

Qualche mese più tardi, grazie a svariati pensieri, si comincio' ad ampliare il sistema dividendo le fasi di autenticazione, scelta servizio e gioco vero e proprio in differenti servers, ognuno utile ad effettuare le diverse operazioni.

I primi risultati non erano quelli sperati. C'erano problemi di sincronizzazione dati e soprattutto problemi in caso uno dei 3 programmi si disconnettesse durante il normale funzionamento, portando il sistema a collassare per desincronizzazione dati.


La sincronizzazione dei dati

Il sistema non poteva considerarsi stabile se non riusciva ad autocontrollarsi in caso di mancanze. Come ben sappiamo è sempre possibile che una connessione remota possa chiudersi e ci sono mille motivi che stanno dietro a questo, pertanto se ogni sistema non riusciva a gestirsi, senza contatti esterni, non poteva considerarsi stabile.
Successivamente si miglioro' decisamente questo aspetto e ora lo stesso puo' considerarsi praticamente perfetto. Tutti e 3 i software riescono a convivere senza alcun problema, anche in caso di errori relativi alla connessione o in caso di gravi perdite pacchetti. Questi aspetti positivi sono dati da un ottimo codice relativo alla sincronizzazione dati, il quale consente di fornire i servizi per i quali è stato scritto anche se al momento non può comunicare con altri servers direttamente connessi. Inoltre, tutto il sistema si basa su una tecnica di ACK (acknowledge) che consente al software di conoscere la reale ricezione ed esecuzione di ogni determinata azione importante.
Un semplice esempio potrebbe essere dato da due servers, il server A e il server B. A è un server che si occupa di comunicare con i client e farli interagire tra loro, mentre B è il server a cui A invia i dati dei client, in modo che vengano salvati in un database. Cosa succede se A perde la connessione con B? In tal caso A non riuscirebbe più a salvare i dati e questo sarebbe un problema. In riferimento al caso esplicato sopra, A riuscirebbe senza problemi a mantenere e accumulare i dati in memoria fino al momento in cui sarebbe nuovamente possibile stabilire una connessione con il server B e, a quel punto, A sarebbe in grado di sincronizzarsi e salvare in B tutti i dati accumulati fino a quel momento, al fine di tornare al normale funzionamento.
Il sistema appena esplicato è quello correntemente utilizzato da VSE.


Il salvataggio differito

Il server finale di connessione con l'utente remoto, che consente l'interattivita tra tutti gli utenti connessi, invia la struttura di informazioni relativa ad ogni personaggio al server che si occupa si salvare questi dati. Se questo non risulta raggiungibile entra in funzione un sistema di accumulazione che termina nel momento in cui è possibile nuovamente stabilire una connessione tra i due servers. In tal occasione la sincronizzazione ha inizio.

In questo modo è garantita la fornitura del servizio anche in caso di problemi relativi alla rete.


I sistemi principali

Arrivati a questo punto, a cosa è dovuta l'implementazione di 3 sistemi separati, piuttosto che un unico sistema?
La risposta è semplice. La scelta sta tutta nella flessibilità dei sistemi.
In questo modo i servers possono essere allocati in differenti zone, a differenza del servizio offerto, e gli amministratori possono disporre di risorse non centralizzate per fornire tutto ciò che vogliono offrire. Per esplicare le caratteristiche migliori di questo sistema occorre prima spiegare alcuni concetti.

Il sistema è basato su 3 sistemi principali: il server di autenticazione, il server di servizio e il server di ambiente.
Il server di autenticazione, in fase di connessione da parte di un client, crea 2 codici casuali di sicurezza. A questo punto, lo stesso, invia due pacchetti principali:
- Il primo viene inviato al client, è contiene il primo codice di sicurezza.
- Il secondo viene inviato a tutti i server di servizio connessi e contiene il primo e secondo codice; gli stessi inviano il secondo codice a tutti i server di ambiente a loro volta connessi.
Non succede tutto esattamente in questo ordine e tempo, ma la spiegazione è utile per capire il concetto.
Una volta effettuate queste operazioni viene inviata al client, da parte del server di autenticazione, la lista dei servers di servizio connessi allo stesso.
Da parte del client, a questo punto, avviene la scelta del servizio, da parte dell'utente.
Una volta scelto il servizio il client riceve le informazioni sul server di servizio selezionato ed effettua la disconnessione dal server di autenticazione, per connettersi al servizio scelto, utilizzando il primo codice di sicurezza. Considerando nessun problema, il server accetta la connessione e consente all'utente di scegliere il proprio servizio. Una volta che l'utente ha scelto il servizio, il client riceve le informazioni relative al secondo codice di sicurezza e al server di ambiente, ovvero quello finale di connessione, per poi disconnettersi e connettersi al server di ambiente utilizzando i nuovi dati di autenticazione.
A questo punto l'utente può interagire con tutti gli altri membri online rimanendo connesso a quest'ultimo server.


La distribuzione del lavoro

Ora, estendendo il discorso precedente e si aggiungono delle mappe (zona, luogo) dove ogni servizio (personaggio) può stare, il sistema diventa ancora piu' complesso.
Abbiamo 200 mappe, interconnesse tra loro tramite portali. Quindi abbiamo un server di autenticazione, un server di servizio e un server di ambiente, che si occupa di mantenere 200 mappe.
Oltre a questo abbiamo 1000 utenti online, sparsi per le mappe.

Server di autenticazione --> Server di servizio --> Server di ambiente con 200 mappe.

Cosa facciamo se la banda a disposizione non è sufficente a mantenere tutti gli utenti online contemporaneamente? In una situazione normale niente. In questa situazione, invece, possiamo semplicemente aggiungere un ulteriore server di ambiente al nostro sistema, facendolo connettere al server di servizio da un'altra locazione e assegnando allo stesso 100 mappe, spostandole del nostro precedente server di ambiente.

Server di autenticazione --> Server di servizio --> Server di ambiente numero 0 con 100 mappe e numero 1 con altre 100 mappe.

Il server di servizio, in questo caso, consente di mantenere i dati sincronizzati tra i due server di ambiente, in modo che ogni utente del server 0 possa comunicare e svolgere qualsiasi azione con un utente presente nel server 1 e viceversa, senza alcun problema.

Oltre alle azioni lato utente, le quali non subiscono variazioni visibili, è garantito il salvataggio dati senza problemi di alcun genere ed evitando eventuali conflitti che potrebbero sopraggiungere in caso determinate azioni vengano svolte in modo contemporaneo tra loro. La gestione dei salvataggi, in caso di un sistema dotato di più server di ambiente, viene gestito in modo totalmente intelligente e basato su priorità. Questo sistema consente, oltretutto, di avere sempre un unico database centralizzato per tutti i dati che riguardano il mondo che il sistema stesso crea, nel suo insieme.

Un utente non vede alcuna differenza, può cambiare mappa vagando tra i due server di ambiente, può comunicare con utenti di server differenti, può fare qualsiasi altra azione, tutto in modo completamente trasparente.
Tutto il sistema viene visto dall'occhio dell'utente come qualcosa di unico. Ciò è particolarmente importante quando si vuole estendere un sistema senza recare disturbo a utenti che fanno già parte di quel sistema e non accetterebbero modifiche sostanziali nelle modalità con le quali sono abituati a convivere.


L'estensione del sistema

Se, a questo punto, volessimo estendere la nostra rete, portando il carico utenti a 10000? Nessun problema. Tutto sta nella distribuzione uniforme di risorse.
Dato che i server di ambiente dialogano con il server di servizio e inviano a quest'ultimo tutti i dati necessari da salvare, una grossa quantità di server di ambiente potrebbe arricchire troppo il carico di lavoro del server di servizio? Ovviamente no.
Il sistema di dialogo tra i due server è caratterizzato da un avanzata gestione delle priorità, la quale consente lo scambio pacchetti di dati immediati, quali le informazioni di inter-comunicazione (messaggi privati, per esempio), in modo istantaneo, anche in condizioni di pesante traffico dati. La priorità di comunicazione distribuita consente di dare spazio ai dati immediati e contemporaneamente preoccuparsi di salvare i dati in modo differito.
Questo sistema consente di avere una massima flessibilità in termini di offerta del servizio e dimensioni dello stesso.


L'aggiunta di ulteriori servizi

Immaginando di voler creare due sistemi paralleli per offrire due servizi differenti. C'è bisogno di creare tutta la rete nuovamente? No.
L'unica cosa da fare è configurare un secondo server di servizio, per fare in modo che si connetta al server di autenticazione esistente e aggiungere a questo tutti i server di ambiente desiderati.

L'utente, a questo punto, ha solo bisogno di connettersi con i propri dati e successivamente scegliere il servizio a cui connettersi, tra i due proposti, per ricevere i dati di autenticazione e procedere all'utilizzo del servizio.

In questo modo è possibile avere il massimo controllo sull'utenza, utilizzando lo stesso database relativo agli utenti per entrambi i sistemi.


Script

VES è capace di interpretare un complesso linguaggio di scripting, tramite il quale è possibile configurare ogni minimo particolare del sistema. Gli script consentono di aggiungere nuove caratteristiche all'ambiente virtuale. La semplicità del linguaggio consente a persone senza qualifiche in ambito programmativo di creare nuovi elementi e modificare l'intero ambiente in modo semplice e intuitivo.
Attraverso il linguaggio di scripting è possibile:
- Gestire gli elementi dell'ambiente virtuale
- Gestire timers
- Gestire entità
- Gestire dialoghi interattivi
- Modificare qualsiasi parametro ambientale
- Modificare i parametri di un servizio

Il linguaggio è composto da un insieme di funzioni imperative, per esempio if, else, while, for, set, echo, e un insieme di oltre 200 funzioni utili a modificare in tempo reale qualsiasi variabile d'ambiente.


Estensioni

Opengroups: Tramite un modulo del CMS Opengroups è possibile visualizzare tutti i dati operativi di VES in tempo reale, permettere agli utenti di poter interagire con i propri dati di accesso e visualizzare informazioni direttamente dal server.
In sostanza il modulo consente di fornire una completa interfaccia web ai mondi virtuali gestiti da VES.
Funzioni disponibili:
- Registrazione
- Modifica dati personali
- Modifica password
- Modulo utile a invitare i propri conoscenti su VES
- Visualizzazione utenti connessi
- Ricerca entità presenti su VES
- Ricerca oggetti presenti su VES e loro caratteristiche
- Statistiche totali
- Statistiche utenti
- Statistiche entità
- Statistiche oggetti
- Statistiche gruppi e comunità
- Statistiche tipi
- Statistiche mappe
- Calcolo probabilità eventi

Construct: Estensione che consente di interagire su VES attraverso una interfaccia tridimensionale. Il modulo VES di Construct è correntemente studiato nell'ottica di un videogioco MMORPG dove gli utenti interagiscono tra loro all'interno di un mondo completamente dinamico.