Ange-Marie MAURIN - A2M Systèmes
eb4db9e01f
ADR 0009 (Proposée) et spécification du protocole Core - rendu 0.1. Le Core projette le monde simulé (micro-mode 2D, SIMULÉ) en deltas SEQUA 3D (sequa::core_render) et les pousse après chaque tick qui change la scène (RenderHub, observateur de LiveSession) ; il lance et supervise sequa-render (RenderSupervisor : lié au Core, relance après plantage). sequa-render charge une bibliothèque d'adaptateur par un point d'entrée C versionné (3d/adapter_library.hpp), applique les deltas et rend les images ; codec JSON provisoire partagé dans 3d/wire. Adaptateur Godot en DLL et nouvel adaptateur de débogage (engines/debug/adapter : vue de côté en images PPM ou vidéo via ffmpeg externe). Protocole Studio - Core 0.3 : render/start, render/stop, render/status (Core et Studio host). Mesuré avec Godot : transport tick -> delta reçu p95 ≈ 0,3 ms (critère 4 ms).
Studio host — brique client
Client C++ du protocole Studio - Core 0.2 côté Studio host
(docs/specs/protocole-studio-core-0.2.md §2, §3, §4 ; ADR 0006).
Bibliothèque statique sequa_host_client (alias sequa::host_client), en-têtes publics dans
include/sequa/studio/host/, espace de noms sequa::studio::host. Aucune exception ne remonte
à l'appelant : les opérations renvoient un type résultat (Result<T>) portant soit une valeur,
soit une Error (code + message).
Rôle
L'hôte n'accède au Core que par ce client :
- se connecter (
hello/welcome), s'attacher ou se détacher (core/attach,core/detach) ; - piloter la session (
session/start,session/pause,session/resume,session/input,session/status) ; - exporter/importer un enregistrement et comparer les empreintes tick par tick lors du rechargement par rejeu (§7.6).
Il ne fait pas : lancer le Core, gérer le processus, le fichier d'exécution, ni le service
HTTP (autres briques de studio/host/).
API publique
wire.hpp — représentations du protocole (§2) :
std::string to_hex64(std::uint64_t)/std::optional<std::uint64_t> from_hex64(std::string_view): entiers 64 bits en 16 caractères hexadécimaux minuscules ; analyse stricte.std::string base64_encode(std::span<const std::uint8_t>)/(std::string_view)etstd::optional<std::vector<std::uint8_t>> base64_decode(std::string_view): base64 standard RFC 4648, décodage strict.std::optional<std::vector<std::uint64_t>> decode_hashes(std::string_view): base64 -> tableau d'empreintesuint64petit-boutiste.std::optional<std::size_t> first_divergence(hashesA, hashesB): premier tick divergent, ounulloptsi identiques.
client.hpp — client :
struct Welcome { std::string protocol_version, core_version, instance_id;
std::int64_t pid; bool linked; };
ConnectResult connect(const std::string& url, std::chrono::milliseconds timeout);
RequestResult request(const std::string& type, const nlohmann::json& payload,
std::chrono::milliseconds timeout);
bool connected() const noexcept;
void close();
void on_disconnect(std::function<void(std::uint16_t, const std::string&)> callback);
std::uint64_t ignored_message_count() const noexcept;
request() est sans état partagé : plusieurs fils peuvent l'appeler en parallèle, chacun avec
un id unique et reçoit sa réponse (les messages sans id ou d'id inconnu sont ignorés
et comptés). Les délais dépassés et les déconnexions sont signalés par Error::code
(Timeout, ConnectFailed, ServerError, Closed, MalformedResponse,
IncompatibleVersion, NotConnected).
Dépendances
- IXWebSocket — BSD-3-Clause (lien PRIVÉ : non exposé dans l'interface publique).
- nlohmann/json — MIT (lien PUBLIC : les charges utiles de l'API sont des
nlohmann::json). - Le code de cette brique et les tests sont sous MPL 2.0.
Tests
sequa_host_client_tests (doctest) s'exécute contre un faux serveur WebSocket minimal qui
suit la spec (welcome, réponses avec id recopié, error, requête lente, fermeture
volontaire). Il ne dépend pas de sequa_core_server.