Gamecard: Almacenamiento de archivos
Este módulo nos permitirá implementar nuestro propio almacenamiento de archivos, que almacene los datos de los distintos Pokemon que se encuentren en el mapa. Para esto, se deberá implementar el FileSystem TALL_GRASS explicado en los siguientes apartados.
Este proceso, se comunicará con los demás de dos posibles maneras:
- A través de la conexión con el
Brokerasociándose globalmente a la cola de mensajesNEW_POKEMON,CATCH_POKEMONyGET_POKEMON. - A través de un socket de escucha en el cual podrá recibir mensajes de las colas de mensajes mencionadas en el punto anterior.
Cabe aclarar que el Proceso Game Card debe poder ejecutarse sin haber establecido la conexión con el Broker, es decir, si el Broker se encuentra sin funcionar, o se cae durante la ejecución, el proceso Game Card debe seguir procesando sus funciones sin el mismo.
En caso que la conexión no llegue a realizarse o se caiga, el proceso Game Card deberá contar con un sistema de reintento de conexión cada X segundos configurado desde archivo de configuración. Esto permitirá que, en caso de caerse el Broker, este se inicie posteriormente al mismo; produciendo que el proceso Game Card pueda asociarse a las colas sin necesidad de reiniciarse.
El FileSystem Tall Grass es un componente creado con propósitos académicos para comprender el funcionamiento básico de la gestión de archivos en un sistema operativo.
La estructura básica del mismo se basa en una estructura de árbol de directorios para representar la información administrativa y los datos de los entidades/Pokemon en formato de archivos. El árbol de directorios tomará su punto de partida del punto de montaje del archivo de configuración.
Durante las pruebas no se proveerán archivos que tengan estados inconsistentes respecto del trabajo práctico, por lo que no es necesario tomar en cuenta dichos casos.
Este archivo tendrá la información correspondiente a la cantidad de bloques y al tamaño de los mismos dentro del File System. Dentro del archivo se encontrarán los siguiente campos:
- Block_size: Indica el tamaño en bytes de cada bloque
- Blocks: Indica la cantidad de bloques del File System
- Magic_Number: Un string fijo con el valor “TALL_GRASS”
Ej:
BLOCK_SIZE=64
BLOCKS=5192
MAGIC_NUMBER=TALL_GRASS
Dicho archivo deberá encontrarse en la ruta [Punto_Montaje]/Metadata/Metadata.bin
Este será un archivo de tipo binario donde solamente existirá un bitmap, el cual representará el estado de los bloques dentro del FS, siendo un 1 que el bloque está ocupado y un 0 que el bloque está libre.
La ruta del archivo de bitmap es: [Punto_Montaje]/Metadata/Bitmap.bin
Los archivos dentro del FS se encontrarán en un path compuesto de la siguiente manera:
[Punto_Montaje]/Files/[Nombre_Archivo]
Donde el path del archivo incluye el archivo Metadata. Ej:
/mnt/TALL_GRASS/Files/Pikachu/Metadata.bin
Dentro del archivo Metadata.bin se encontrarán los siguientes campos:
- Directory: indica si el archivo en cuestión es un directorio o no (Y/N).
- Size: indica el tamaño real del archivo en bytes (en caso de no ser un directorio).
- Blocks: es un array de números que contiene el orden de los bloques en donde se encuentran los datos propiamente dichos de ese archivo (en caso de no ser un directorio).
- Open: indica si el archivo se encuentra abierto (Y/N).
Ej Directorio:
DIRECTORY=Y
Ej Archivo:
DIRECTORY=N
SIZE=250
BLOCKS=[40,21,82,3]
OPEN=Y
De esta manera podremos formar el siguiente árbol de archivos en donde la metadata dentro del directorio Files contiene un DIRECTORY con valor Y y Pikachu tiene un metadata con un DIRECTORY con el valor N.
/mnt/TALL_GRASS/Files/Metadata.bin
/mnt/TALL_GRASS/Files/Pikachu/Metadata.bin
Los datos estarán repartidos en archivos de texto nombrados con un número, el cual representará el número de bloque. (Por ej 1.bin, 2.bin, 3.bin). Dichos archivos se encontraran dentro de la ruta:
[Punto_Montaje]/Blocks/[nroBloque].bin
Ej:
/mnt/TALL_GRASS/Blocks/1.bin
/mnt/TALL_GRASS/Blocks/2.bin
Ezequiel Gauna Agosto de 2020:
