Protocole PC–mobile

#Transport et versions

Les capacités production déclarent LAN v1, WebRTC v1 et relais v2. La sélection teste les chemins directs avant de valider le relais. Les versions doivent être contrôlées aux deux extrémités; un manifeste ne remplace pas un test d’activation.

#Cycle d’un tour

1. 1
   Le client crée des identifiants de requête et de tour.
2. 2
   Le transport autoritaire remet une seule demande au serveur PC.
3. 3
   Le serveur associe les fragments et l’événement terminal à la conversation et au tour.
4. 4
   La persistance idempotente évite le double ajout.
5. 5
   Une répétition du même identifiant peut se rattacher; une demande différente concurrente est rejetée.

#Règle de coupure

Une perte de connexion après le début d’un tour n’entraîne ni réémission ni changement de transport pour ce tour. Cette règle est une propriété de sûreté contre les doubles effets. La reconnexion sert au tour suivant et à la récupération d’état persistant.

#Protocole transactionnel des pièces jointes

ATTACHMENT_PREPARE annonce de 1 à 10 fichiers, leur taille, SHA-256 et nombre de fragments. Chaque ATTACHMENT_CHUNK transporte au plus 20 KiB sur le transport déjà choisi. Le PC confirme chaque fichier après vérification de la taille exacte et du hash, puis ATTACHMENT_COMMIT rend le lot consommable par un seul tour.

• 20 MiB maximum par fichier et pour le lot complet, en octets binaires.
• Aucune requête modèle avant commit complet.
• Pas de bascule de transport ni de renvoi automatique en cours de lot.
• Annulation et échec suppriment le lot; expiration à 15 minutes; nettoyage d’orphelin après 1 heure.
• Images vers vision compatible; fichiers génériques vers le chemin local temporaire; erreur explicite si le fournisseur n’a pas la capacité.

#Trames et anti-abus

Le LAN et le relais appliquent en plus leurs plafonds de trame, fragments, débit et pression. Ces seuils opérationnels protègent le service et peuvent évoluer; ils ne modifient pas le contrat produit de 10 fichiers et 20 MiB par message.