ajout du readme.md de la version unsecured

This commit is contained in:
Moncef STITI 2024-12-03 20:58:51 +01:00
parent a2a1298927
commit c5600c90a6

@ -1,31 +1,120 @@
@TODO : Améliorer le README.MD (le texte y compris)
# 🔓 Transactions Non Sécurisées
Ce programme simule des transactions bancaires concurrentes sans mécanismes de protection. Les processus effectuent des transferts entre comptes bancaires stockés dans un fichier de base de données. Cependant, en l'absence de verrouillage, des incohérences peuvent survenir lorsque plusieurs processus accèdent simultanément au fichier.
# 🏦 Simulateur de Transactions Bancaires Concurrentes
## 📋 Description du Programme
Le programme exécute plusieurs processus en parallèle, chacun effectuant un certain nombre de transactions aléatoires entre des comptes bancaires.
Ce programme en C simule des transactions bancaires aléatoires entre comptes dans un environnement multi-processus. Il est conçu pour illustrer les défis de la concurrence sans synchronisation explicite.
### Fonctionnalités principales :
1. **Lecture/Écriture de comptes :**
Les comptes sont lus et écrits dans un fichier (`accounts.db`), chaque ligne représentant un compte avec un nom et un solde.
## ✨ Fonctionnalités
2. **Transactions aléatoires :**
Chaque processus effectue des transactions aléatoires entre deux comptes. Le montant transféré est d'au maximum 20 % du solde du compte débité.
- 📖 **Lecture et écriture de comptes** : Les comptes sont stockés dans un fichier avec un format fixe (nom et solde).
- 🔄 **Transactions aléatoires** : Effectue des transferts d'argent aléatoires entre comptes.
- 🤹 **Simulation multi-processus** : Plusieurs processus enfants effectuent des transactions simultanément.
- 📊 **Calcul des soldes** : Affiche le solde total avant et après les transactions.
3. **Absence de verrouillage :**
Aucune protection n'est mise en place pour gérer les accès concurrents au fichier. Cela peut entraîner des écritures corrompues ou des pertes de données.
---
4. **Calcul du solde total :**
Le solde total des comptes est calculé avant et après les transactions pour détecter d'éventuelles incohérences.
## ⚠️ Limitations et Bugs Potentiels
## ⚙️ Compilation et Exécution
### Compilation
Utilisez le fichier `Makefile` pour compiler le programme :
```bash
make
```
Cela génère un exécutable nommé `unsecured_transaction`.
🚨 **Ce programme n'utilise pas de mécanismes de verrouillage pour gérer la concurrence.**
### Exécution
Exécutez le programme en spécifiant :
- Le nombre de processus à lancer.
- Le nombre de transactions par processus.
1. **💥 Problème de concurrence** :
- Plusieurs processus peuvent lire et écrire dans le fichier en même temps, entraînant des incohérences dans les soldes (race condition).
- Par exemple, deux processus modifiant simultanément un compte peuvent écraser leurs changements.
Exemple :
```bash
./unsecured_transaction 4 10
```
Ici, 4 processus seront lancés, chacun effectuant 10 transactions.
2. **📉 Corruption des données** :
- Une interruption (crash ou arrêt forcé) pendant une transaction peut laisser des données partiellement écrites.
## 🛑 Problèmes et Limites
En raison de l'absence de verrouillage, plusieurs problèmes peuvent survenir, en particulier dans des situations d'accès concurrent à la base de données :
### **1. Incohérences des Données :**
Sans mécanismes de synchronisation, deux processus peuvent tenter de lire, modifier et réécrire les données d'un même compte simultanément. Cela entraîne des écritures corrompues, où le solde d'un compte peut être incorrect. Par exemple, deux processus peuvent lire un solde identique, effectuer une transaction basée sur ce solde, puis écrire deux fois ce même solde mis à jour, écrasant ainsi les modifications apportées par l'autre processus.
**Exemple d'incohérence :**
- Le **processus 1** lit le solde de `Alice` (1000€).
- Le **processus 2** lit également le solde de `Alice (1000€).
- Le **processus 1** transfère 100€ de `Alice` à `Bob`, et écrit 900€ dans le fichier.
- Le **processus 2** effectue une transaction de 200€ de `Alice` à `Charlie`, et écrit 800€ dans le fichier, perdant la modification effectuée par le **processus 1**.
3. **❌ Absence de validations robustes** :
- Aucune vérification supplémentaire pour s'assurer que les montants transférés sont cohérents en cas de concurrence.
### **2. Solde Final Incorrect :**
Après l'exécution des transactions, le solde total des comptes peut ne pas correspondre au solde initial en raison des conflits d'écriture. Par exemple, une transaction pourrait ne pas être correctement appliquée à cause de la lecture et de l'écriture concurrentes sur les mêmes données.
**Exemple de sortie :**
```plaintext
Solde total initial : 10000€
Transaction : Alice -> Bob : 50€
Transaction : Bob -> Alice : 30€
...
Solde total final : 9990€
Le solde final est différent du solde initial...
```
### **3. Absence de Contrôle des Transactions :**
Sans un mécanisme de verrouillage, il est impossible de garantir qu'une transaction soit complète avant qu'une autre ne soit lancée. Par exemple, un transfert de 100€ entre `Alice` et `Bob` peut être partiellement effectué si le programme est interrompu au moment de l'écriture.
## 📜 Exemple de Résultat
### Avant l'exécution
Le fichier [`accounts.db`](../Data/accounts.db) contient :
```plaintext
...
Diana 7145
Diego 8494
Dominic 4487
Dylan 1157
Easton 429
Eden 5737
Edward 3671
Elaina 4904
...
```
### Compilation et exécution
On compile le programme avec :
```bash
make
```
ou
```bash
gcc unsecured_transaction.c -o unsecured_transaction
```
On exécute avec la commande suivante :
```bash
./unsecured_transaction 30 40
```
### Après l'exécution
On obtient cette sortie sur la console :
```plaintext
Solde total initial : 400000€
...
Transaction : Alivia -> Kaiden : 14€
Transaction : Arianna -> Barrett : 3€
Transaction : Rosalie -> Connor : 1€
Transaction : Sara -> Arthur : 190€
Transaction : Jude -> Sadie : 41€
...
Solde total final : 4004785€
Le solde final est différent du solde initial...
Tout les processus sont terminés !
```
## 🚀 Points à Améliorer
- **Ajout de verrouillage :** Utiliser des mécanismes comme lockf pour sécuriser les accès concurrents au fichier.
- **Détection de conflits :** Identifier et gérer les conflits d'écriture pour éviter les pertes de données.
Pour voir une version améliorée avec des verrous, consultez la section [🔒 Transactions Sécurisées](../Secured).
---