4nk/sdk_common
5
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

fix ia "dreams"

Browse Source
This commit is contained in:
NicolasCantu 2024-02-13 13:16:38 +01:00
parent 4429049129
commit 20bb9817cf
3 changed files with 51 additions and 49 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
doc/Messages-SP-Specs.md
View File

@ -56,8 +56,12 @@ Les relais sont ainsi partagés sous forme d'objets `SharedPeer` (décris dans [
## 4. <a name='Tailledesdonnes'></a>Taille des données
Les objets `SharedPeer` indiquent la taille maximale des données pour les messages de type `Message` et de type `MessageConnect` dans l'attribut `data_max_size`. Les messages plus gros que cette taille sont rejetés.
## 5. <a name='Preuvedetravail'></a>Preuve de travail
Les objets `SharedPeer` indiquent les caractéristiques de la preuve de travail pour les messages de type `Message` et de type `MessageConnect` dans les attributs `pow_difficulty`, `pow_pattern`, , `pow_prefix`, `pow_nonce`, timestamp. Les messages ne satisfaisant pas à la preuve de travail sont rejetés.
## Partage de la liste de relais
## Parage de la liste de process

46
doc/Specs-Code.md
View File

@ -1,15 +1,16 @@
<!-- vscode-markdown-toc -->
* 1. [Gestion des erreurs](#Gestiondeserreurs)
* 2. [Journalisation et monitoring](#Journalisationetmonitoring)
* 3. [Tests](#Tests)
* 3.1. [Stratégie de test](#Stratgiedetest)
* 3.2. [Plan pour les tests unitaires](#Planpourlestestsunitaires)
* 3.3. [Plan d'intégration](#Plandintgration)
* 3.4. [Plan de charge](#Plandecharge)
* 4. [Outils et les librairies à utiliser](#Outilsetleslibrairiesutiliser)
* 5. [Critères d'acceptation](#Critresdacceptation)
* 6. [CI/CD](#CICD)
* 7. [Maintenance](#Maintenance)
* 1. [Documents de référence](#Documentsderfrence)
* 2. [Gestion des erreurs](#Gestiondeserreurs)
* 3. [Journalisation et monitoring](#Journalisationetmonitoring)
* 4. [Tests](#Tests)
* 4.1. [Stratégie de test](#Stratgiedetest)
* 4.2. [Plan pour les tests unitaires](#Planpourlestestsunitaires)
* 4.3. [Plan d'intégration](#Plandintgration)
* 4.4. [Plan de charge](#Plandecharge)
* 5. [Outils et les librairies à utiliser](#Outilsetleslibrairiesutiliser)
* 6. [Critères d'acceptation](#Critresdacceptation)
* 7. [CI/CD](#CICD)
* 8. [Maintenance](#Maintenance)
<!-- vscode-markdown-toc-config
numbering=true
@ -17,12 +18,11 @@
/vscode-markdown-toc-config -->
<!-- /vscode-markdown-toc --># Specs - Code
## 1. <a name='Documentsderfrence'></a>Documents de référence
Voir [Doc_references.md](Doc_references.md).
## 1. <a name='Gestiondeserreurs'></a>Gestion des erreurs
## 2. <a name='Gestiondeserreurs'></a>Gestion des erreurs
Les processus doivent continuer malgré des "sous" traitements/threads en échec et les fonctions doivent être `catch` si il y a une possiblité d'interuption.
@ -36,7 +36,7 @@ Les arrêts des membres dans les process dans leur ensemble n'entraînent pas d'
Les parties prenantes ont tous les moyens organisationnels dans les process, pour procéder au bon redémarrage des services en cas de dégradations et de situations inattendues, avec le versionning des relais et des membres des rôles; ainsi que des conditions contractuelles avec leurs implications opérationnelles et possiblement économiques.
## 2. <a name='Journalisationetmonitoring'></a>Journalisation et monitoring
## 3. <a name='Journalisationetmonitoring'></a>Journalisation et monitoring
Tous les utilisateurs reçoivent les mêmes flux qu'ils se relaient et se restituent au démarrage, tous les flux ont une empreinte horodatée sur une timechain et peuvent être demandés unitairement entre parties, avec le même niveau de confidentialité par rôles. Les PCD sont les listes à jour de l'état de validation de tous les éléments échangés, et les PRD sont toutes les signatures échangées sur les flux; en mémoire côté utilisateur, par "session" sur un nœud, pour un process (possible de segmenter par zones et services).
@ -44,27 +44,27 @@ Le monitoring comme la journalisation, ne sont pas possibles et pas pertinents s
La timechain permet de monitorer l'activité générale sur la side chain avec un nombre de jetons échangés (le même nombre à chaque message) et des ancrages critiques sont monitorables sur le mainnet publiquement par n'importe qui (mais non exploitable fonctionnellement). Ainsi seul le bon fonctionnement est monitorable, par tous, facilement, sans métadonnées exploitables pour ce qui est des usages qui restent donc confidentiels.
## 3. <a name='Tests'></a>Tests
## 4. <a name='Tests'></a>Tests
### 3.1. <a name='Stratgiedetest'></a>Stratégie de test
### 4.1. <a name='Stratgiedetest'></a>Stratégie de test
À l'issue du développement en ScrumBan, chaque ticket fait l'objet d'une revue de code, et d'un test par un testeur.
### 3.2. <a name='Planpourlestestsunitaires'></a>Plan pour les tests unitaires
### 4.2. <a name='Planpourlestestsunitaires'></a>Plan pour les tests unitaires
Les tests unitaires seront ajoutés par un testeur, ainsi toutes les fonctionnalités reçues auront un test unitaire.
### 3.3. <a name='Plandintgration'></a>Plan d'intégration
### 4.3. <a name='Plandintgration'></a>Plan d'intégration
L'intégration se réalise par sprint hebdomadaire.
L'ensemble des fonctionnalités livrées dans le sprint doivent être testées dans un parcours d'intégration écrit et testé par un testeur en fin de sprint.
### 3.4. <a name='Plandecharge'></a>Plan de charge
### 4.4. <a name='Plandecharge'></a>Plan de charge
Tous les 2 sprints, des tests aux limites sont définis et mis en œuvre par un testeur depuis la simulation des comportements des utilisateurs.
## 4. <a name='Outilsetleslibrairiesutiliser'></a>Outils et les librairies à utiliser
## 5. <a name='Outilsetleslibrairiesutiliser'></a>Outils et les librairies à utiliser
Respect des normes de syntaxe Rust.
@ -82,7 +82,7 @@ Utilisation de Visual Studio (pour le partage de configurations).
* **Librairies de tests** : Cargo test
## 5. <a name='Critresdacceptation'></a>Critères d'acceptation
## 6. <a name='Critresdacceptation'></a>Critères d'acceptation
Critères de validation pour que le système puisse être considéré comme prêt pour la production :
@ -96,11 +96,11 @@ Critères de validation pour que le système puisse être considéré comme prê
* Documentation manquante clairement précisée.
* Autres tests manquants clairement précisés.
## 6. <a name='CICD'></a>CI/CD
## 7. <a name='CICD'></a>CI/CD
GitLab CI : TBD
## 7. <a name='Maintenance'></a>Maintenance
## 8. <a name='Maintenance'></a>Maintenance
La liste des dépendances doit être maintenue dans le readme des projets, mise à jour à chaque fin de sprint.
Les tests de fin de sprint doivent intégrer une revue des dernières versions et alertes sur les librairies en dépendance.

50
doc/Specs-Datamodel.md
View File

@ -534,11 +534,31 @@ SharedProcess identifies a shared process within the system, aiding in the manag
### 5.6. <a name='SharedPeer'></a>SharedPeer
SharedPeer specifies a peer shared within the network, playing a key role in distributed information sharing and communication.
SharedPeer specifies a peer within the network, playing a key role in distributed information sharing and communication.
| Attribute Name | Type | Option | Description |
|----------------|----------|--------|-------------------------------------------------------------------------------|
| domain | String | | The domain associated with the shared peer. |
| address_ip | String | | The IP address of the shared peer. |
| relay | Relay | | Represents a relay node in the network. |
| l1_node | L1Node | | Represents a level 1 (L1) node in the network. |
| l1_miner | L1Miner | | Represents a level 1 (L1) miner in the network. |
| l2_node | L2Node | | Represents a level 2 (L2) node in the network. |
| l2_certif | L2Certif | | Represents a level 2 (L2) certification authority or function in the network. |
## 11. <a name='Relay'></a>Relay
Represents a relay in the network, specifying its address and port, data handling capacity, and Proof of Work (PoW) requirements.
| Attribute Name | Type | Option | Description |
|----------------|--------|--------|-------------------------------------------------------------------|
| address_port | u16 | | The port address of the relay. |
| data_max_size | usize | | Maximum size of data the relay can handle. |
| pow_difficulty | u32 | | The difficulty level for the Proof of Work required by the relay. |
| pow_pattern | String | | The pattern used for the Proof of Work. |
| pow_prefix | String | | The prefix used for the Proof of Work. |
| Attribute Name | Type | Option | Description |
|----------------|--------|--------|--------------------------------------------------------------------------------------------------------------------------------|
| peer_id | String | | The identifier for the shared peer, facilitating the distribution and communication of information among peers in the network. |
### 5.7. <a name='L1Node'></a>L1Node
@ -592,15 +612,6 @@ L2Certif specifies a Layer 2 certification authority, including its network and
| status | String | | Current status of the L2 certification authority (e.g., active, inactive). |
| certif_type | String | | Type of certification or service provided by the L2 certif. |
### 5.11. <a name='SharedPeer-1'></a>SharedPeer
| Attribute Name | Type | Option | Description |
|----------------|--------|--------|------------------------------------------------------|
| peer_id | String | | Unique identifier for the peer. |
| ip_address | String | | IP address of the peer. |
| port | u16 | | Port number the peer is listening on. |
| status | String | | Current status of the peer (e.g., active, inactive). |
## 6. <a name='Metadata'></a>Metadata
MetaDataa aggregates various metadata types, including tags, zones, and key lists, offering a comprehensive view of metadata for diverse applications.
@ -974,19 +985,6 @@ The RolePeer struct identifies peers associated with specific roles, detailing t
| peers | Vec<SharedPeer> | | List of peers associated with this role. |
| metadata | HashMap<String, String> | | Metadata associated with the role. |
## 11. <a name='Relay'></a>Relay
Relay is associated with the infrastructure that facilitates the relay of information or transactions between different parts of the system. It includes identifiers, IP addresses, ports, status, and types of relay nodes, crucial for maintaining connectivity and ensuring the efficient distribution of data and transactions across the network.
| Attribute Name | Type | Option | Description |
|----------------|---------------|--------|-------------------------------------------------------|
| id | u32 | | Unique identifier for the relay. |
| ip_address | String | | IP address of the relay. |
| port | u16 | | Port number the relay listens on. |
| status | String | | Current status of the relay (e.g., active, inactive). |
| last_active | DateTime<Utc> | | Timestamp of the last activity seen from the relay. |
| relay_type | String | | Type of the relay (e.g., full, light). |
## 12. <a name='Rustconsiderations'></a>12. Rust considerations
### 12.1. <a name='GeneralImplicationsforProjectObjects'></a> General Implications for Project Objects