Icône de l'app Calíope

Les pilotes que j’écris

Neuf clients, chacun écrit d’après ce que publient ses auteurs.

Calíope parle à huit sortes de serveurs par des clients que j’ai écrits moi-même. Chacun vient de ce que publient ses auteurs : leur spécification et leur documentation ou, là où ils ne publient aucune spécification, comme Oracle, le pilote qu’ils désignent comme référence ; jamais du client de quelqu’un d’autre. Et chacun implémente ce dont Calíope se sert, rien de plus. Cette page les résume en trois parties : d’après quoi il a été écrit, ce qu’il parle, et ce qu’il laisse de côté volontairement, avec la raison.

Derrière chaque résumé il y a une spécification complète : chaque message, chaque méthode d’authentification, comment le client est fait et comment il est testé contre de vrais serveurs. Elle vit dans le dépôt du code, en espagnol, et elle est vérifiée à chaque commit contre le code qu’elle décrit : quand un pilote change, son document doit être relu avant que le changement entre.

MySQL et MariaDB

Écrit d’après

Ce qu’il parle

  • La phase de connexion avec la négociation des capacités, et le TLS qui démarre en plein milieu.
  • L’authentification par mysql_native_password, caching_sha2_password, client_ed25519, parsec et mysql_clear_password, cette dernière seulement par TLS.
  • Les requêtes texte (COM_QUERY) avec plusieurs résultats par réponse, si bien qu’un CALL renvoie ses lignes.
  • Les requêtes préparées (COM_STMT_PREPARE, COM_STMT_EXECUTE, COM_STMT_CLOSE) avec des lignes binaires : les valeurs voyagent à part du SQL.
  • LOCAL INFILE, qui n’envoie que le fichier que vous choisissez.
  • Les lignes affectées, le dernier id inséré, les avertissements et l’état de la transaction, tels que le serveur les donne dans sa propre réponse.
  • L’arrêt d’une requête en cours par KILL QUERY depuis une seconde connexion.

Ce qu’il ne parle pas

  • CLIENT_MULTI_STATEMENTS : jamais déclaré. L’éditeur envoie une instruction à la fois, et sans lui un texte injecté ne peut pas enchaîner une seconde instruction.
  • La compression et le protocole X (port 33060) : aucun outil n’en a besoin.
  • Les curseurs côté serveur : les gros résultats arrivent ligne par ligne.
  • La réplication, COM_CHANGE_USER et les commandes du binlog : aucun outil ne s’en sert.
  • Les autres méthodes d’authentification (sha256_password, Kerberos, LDAP SASL, GSSAPI) : refusées avec le nom de la méthode, si bien que l’erreur dit ce qui manque.
  • Un mot de passe en clair sur une connexion non chiffrée : jamais.
  • Les serveurs antérieurs à MySQL 4.1.

Aussi TiDB

  • TiDB parle ce même protocole, donc il passe par ce même client, mesuré contre TiDB 8.5. Son salut porte 8.0.11-TiDB-v8.5.8, et c’est cette chaîne de version qui dit à Calíope qu’il parle à TiDB, quoi que dise le profil.
  • L’identifiant d’une connexion TiDB peut faire 64 bits alors que le salut n’en porte que les 32 du bas, et un KILL QUERY avec ceux-là n’arrête rien : avec TiDB, je demande CONNECTION_ID() une fois par connexion et j’annule avec l’identifiant entier.
  • Les méthodes de connexion propres à TiDB (tidb_sm3_password, tidb_auth_token) : non parlées, et refusées avec le nom de la méthode, comme toute autre.
  • Son port d’état (10080) et ses métriques Prometheus : un second port qu’il faudrait ouvrir et faire passer par le tunnel. Ce que donne la connexion SQL est affiché, et le reste dit n/a.

PostgreSQL

Écrit d’après

Ce qu’il parle

  • Le TLS demandé avant tout ; si le serveur le refuse, rien ne part en clair.
  • L’authentification par SCRAM-SHA-256, md5 ou mot de passe en clair, ce dernier seulement par TLS.
  • La requête simple et la requête étendue (Parse, Bind, Execute), avec les paramètres à part du SQL.
  • Chaque valeur en texte, le même que montre psql, livrée ligne par ligne à mesure qu’elle arrive.
  • Les lignes affectées, les erreurs et les avis avec tous leurs champs, et l’état de la transaction à chaque réponse.
  • L’annulation par CancelRequest avec la clé que le serveur remet à la connexion, et DISCARD ALL avant qu’une connexion revienne au pool.

Ce qu’il ne parle pas

  • COPY : Calíope ne l’envoie jamais ; un COPY tapé dans l’éditeur ferme la connexion, car le serveur attendrait des données qui ne viendront pas.
  • LISTEN/NOTIFY : les notifications sont lues et écartées.
  • Kerberos (GSSAPI) et SSPI : ils exigent des tickets système que le sandbox ne donne pas.
  • SCRAM avec liaison au canal (SCRAM-SHA-256-PLUS) : le serveur ne peut pas l’exiger, donc cela ne change pas qui entre.
  • Les résultats en binaire, les curseurs nommés, les requêtes préparées nommées et le pipelining : une requête en vol par connexion.
  • Le protocole de réplication et l’appel de fonctions.
  • Un mot de passe en clair sur une connexion non chiffrée : jamais.

MongoDB

Écrit d’après

Ce qu’il parle

  • BSON, type par type, Decimal128 compris.
  • OP_MSG et la poignée de main hello, avec MongoDB 4.0 ou ultérieur.
  • L’authentification par SCRAM-SHA-256 et SCRAM-SHA-1.
  • TLS avec la même politique que les autres moteurs.
  • Les chaînes de connexion mongodb:// et mongodb+srv://, avec les enregistrements SRV et TXT résolus par le DNS du système.
  • Le primaire d’un replica set, lu dans la réponse à hello, et un pool de connexions.

Ce qu’il ne parle pas

  • Tout message autre qu’OP_MSG : un serveur qui ne parle que les anciens est antérieur à la 4.0 et il est refusé.
  • La compression et les curseurs exhaust : chaque commande attend sa réponse.
  • Les sessions, les transactions, les change streams, les écritures réessayables et la lecture des secondaires : les outils ne s’en servent pas, et tout va au primaire.
  • Les méthodes d’authentification qui ne sont pas SCRAM (x.509, Kerberos, LDAP, AWS, OIDC) : l’erreur dit celles qu’offre le serveur.
  • Les types BSON obsolètes : lus et montrés comme non pris en charge, jamais écrits.
  • Les options de fichier de la chaîne (tlsCAFile) : le sandbox ne laisse pas lire un chemin, donc les certificats vont dans le profil.
  • Un nom mongodb+srv:// par un tunnel SSH : c’est l’autre bout qui le résoudrait, pas votre appareil.

Redis

Écrit d’après

Ce qu’il parle

  • RESP2 et RESP3, tous les types, chaque réponse appariée à sa commande par position.
  • L’authentification par HELLO ou AUTH, avec un utilisateur ACL et son mot de passe.
  • SELECT appliqué à chaque connexion quand elle est prêtée, et TLS avec la même politique que les autres moteurs.
  • Le mode cluster : les 16 384 slots, la carte relue après un MOVED, un ASK valable une seule fois.
  • Une console qui vérifie chaque commande que vous tapez contre une liste avant qu’elle atteigne le serveur.
  • Un Sentinel, ouvert depuis son propre profil : Topologie montre les primaires qu’il surveille, leurs répliques et les autres sentinelles, tels qu’il les décrit (SENTINEL MASTERS, REPLICAS, SENTINELS).

Ce qu’il ne parle pas

  • La forme « inline » des commandes : elle ne peut pas porter des octets arbitraires.
  • Pub/sub et MONITOR : rien dans le client ne s’abonne.
  • Les transactions (MULTI, WATCH), les commandes bloquantes sans délai, CLIENT REPLY OFF, RESET et les commandes de réplication : une connexion du pool est partagée par tous les outils, et elles y laisseraient un état.
  • Le cache côté client, et suivre Sentinel jusqu’au nœud qui est primaire à ce moment-là : le client se connecte à l’adresse du profil.
  • Un cluster par un tunnel SSH : les nœuds annoncent des adresses que le tunnel n’atteint pas, donc c’est refusé avant de se connecter.

Aussi Valkey

  • Valkey parle RESP2 et RESP3 comme Redis, donc il passe par ce même client, mesuré contre Valkey 8.0 et 9.1, en serveur autonome et en cluster avec des slots en migration. HELLO répond server valkey, et c’est ce qui dit à Calíope auquel des deux il parle.
  • Valkey ne publie pas redis_mode: : sans HELLO, le mode se lit dans server_mode: de INFO server.
  • Ce que Valkey ajoute par-dessus (COMMANDLOG, bases numérotées dans un cluster) : non parlé. SLOWLOG existe toujours, et c’est ce que lit Commandes lentes.

SQL Server (TDS)

Écrit d’après

Ce qu’il parle

  • Toujours chiffré : d’abord le mode strict de TDS 8.0, TLS dès le premier octet avec TLS 1.2 ou ultérieur, et la poignée de main de TDS 7.x dans le PRELOGIN quand le serveur n’offre pas le mode strict.
  • PRELOGIN et LOGIN7 (TDS 7.4) avec une connexion SQL Server.
  • Les lots (SQL_BATCH) et les requêtes paramétrées par RPC vers sp_executesql, avec des valeurs typées à part du SQL.
  • Le flux de jetons : colonnes, lignes, comptes, erreurs, messages et changements d’environnement, et les types de SQL Server, spatiaux compris.
  • L’annulation par ATTENTION, et RESETCONNECTION avant qu’une connexion revienne au pool.
  • GO comme séparateur de lots, traité par le client comme le font les outils de SQL Server.

Ce qu’il ne parle pas

  • MARS : une requête par connexion, et une connexion par utilisateur du pool.
  • L’authentification intégrée de Windows (SSPI, Kerberos, NTLM) : elle exige un domaine et un client Kerberos que le sandbox n’a pas.
  • Microsoft Entra ID : c’est un flux OAuth vers Microsoft, un produit à part.
  • Les connexions non chiffrées, ou qui ne chiffreraient que l’ouverture de session : refusées.
  • Le chargement en masse, les requêtes au gestionnaire de transactions et le routage Always On : les transactions voyagent en T-SQL, et les chargements en INSERT.
  • text, ntext, image, hierarchyid et les types CLR utilisateur : montrés comme non pris en charge.

ClickHouse (HTTP)

Écrit d’après

  • La documentation de ClickHouse sur son interface HTTP, ses formats et réglages, la syntaxe des paramètres de requête et ses tables système.
  • RFC 3986, pour encoder la chaîne de requête.
  • Et le serveur lui-même, qui décrit ses réglages, fonctions et types dans ses propres tables system.

Ce qu’il parle

  • HTTP ou HTTPS sur URLSession d’Apple, sans aucune dépendance ajoutée : une instruction par requête, la base dans chaque requête.
  • Les paramètres de requête typés ({nom:Type}) : les valeurs voyagent à part du SQL.
  • Les résultats lus ligne par ligne une fois la requête terminée, si bien qu’une erreur à la fin d’un 200 OK est repérée.
  • Un plafond de lignes renvoyées, écrit à côté du chiffre qu’il limite.
  • Une session seulement pour un lot qui en a besoin, la progression tirée de system.processes, et l’arrêt par KILL QUERY.
  • TLS avec les trois mêmes choix que les autres moteurs ; par un tunnel SSH, le certificat est toujours vérifié contre l’hôte du profil.

Ce qu’il ne parle pas

  • Le protocole natif par TCP (port 9000) et son format : l’interface HTTP donne ce dont Calíope a besoin sans protocole binaire ni dépendance.
  • gRPC et les interfaces qui imitent MySQL ou PostgreSQL.
  • Plusieurs instructions par requête, ou une session par onglet : le serveur refuse deux requêtes à la fois sur une même session.
  • Les données dans le corps de la requête et les tables externes : les insertions de l’app voyagent en SQL.
  • Les certificats client : un profil qui en porte est refusé.
  • Les transactions : le serveur n’en a pas.

Oracle Database (TNS)

Écrit d’après

  • Oracle ne publie pas la spécification de son protocole réseau. Ce qu’il publie, et désigne comme la référence publique, c’est le code du mode thin de son propre pilote Python, python-oracledb, sous la Universal Permissive License 1.0 ou la Apache License 2.0. J’écris d’après lui tel qu’il était le 6 octobre 2026, à une révision fixe ; chaque fichier qui en dérive le dit, et sa licence voyage avec les autres avis de tiers de Calíope.
  • La documentation d’Oracle : la SQL Language Reference, la Database Reference pour les vues du dictionnaire, la référence des paquetages PL/SQL et la Net Services Reference.
  • Les autres clients d’Oracle, quel que soit leur langage, n’ont pas été ouverts.

Ce qu’il parle

  • TNS sur TCP, ou sur TLS (TCPS) vérifié contre les certificats du système ou celui que porte le profil, avec le nom vérifié face à l’hôte du profil, y compris à travers un tunnel SSH, et les redirections du listener.
  • La connexion avec le mot de passe de la base (O5LOGON).
  • Les instructions avec des valeurs typées séparées du SQL, et les lignes par lots ; CLOB et BLOB sont lus en entier jusqu’à un plafond, et au-delà la cellule donne leur taille.
  • L’annulation d’une instruction en cours.

Ce qu’il ne parle pas

  • L’interruption hors bande : SwiftNIO ne peut pas l’envoyer, donc l’annulation passe toujours dans la bande.
  • Le wallet et les certificats client, les jetons d’accès, Kerberos et l’authentification du système d’exploitation : on entre avec le mot de passe, et avec TLS dans un seul sens, et un profil qui porte un certificat client est refusé.
  • Décoder les types objet, les collections, XMLTYPE, le JSON binaire, VECTOR et BFILE : la cellule donne le type à la place.
  • DRCP, le pool de sessions propre au pilote, le pipelining et l’authentification rapide.
  • Advanced Queuing, la validation en deux phases, le chargement en chemin direct et les notifications de changements.
  • tnsnames.ora et sqlnet.ora : le profil porte l’hôte, le port et le service.

Apache Cassandra et ScyllaDB (CQL)

Écrit d’après

  • La spécification du protocole natif v4 que publie le projet Apache Cassandra, à une révision fixe du 3 avril 2025.
  • Ce que ScyllaDB ajoute au protocole et que Calíope lit, les clés SCYLLA_* de SUPPORTED, mesuré contre le serveur.
  • Les autres clients de Cassandra, dans n’importe quel langage, n’ont pas été ouverts.

Ce qu’il parle

  • La version 4 du protocole natif, celle que parlent Cassandra 4.1 et suivantes et ScyllaDB 2025.1 et suivantes, chaque réponse appariée à sa requête par son stream.
  • La connexion par mot de passe (SASL PLAIN contre PasswordAuthenticator), TLS avec certificat client facultatif, et tunnel SSH.
  • Les requêtes avec niveau de cohérence, la pagination par paging_state, les requêtes préparées pour les valeurs, les lots logged et unlogged, et la trace sur demande.
  • Tous les types CQL, écrits comme les écrit cqlsh.
  • Un seul pilote pour les deux serveurs : OPTIONS reçoit sa réponse avant la connexion, et les clés SCYLLA_* de cette réponse disent à Calíope auquel des deux il parle.

Ce qu’il ne parle pas

  • La version 5 du protocole et les suivantes : la 4 est celle que parlent les deux serveurs dans toutes les versions que Calíope prend en charge.
  • La compression, et REGISTER avec ses événements : un client de bureau n’a l’usage ni de l’une ni des autres.
  • Le routage par jeton : le client parle au point de contact du profil, ou à son alternative.
  • La connexion par Kerberos et LDAP.

Elasticsearch et OpenSearch (REST)

Écrit d’après

  • La spécification de l’API REST que publie Elastic, et celle que publie le projet OpenSearch, toutes deux à une révision fixe : celle d’Elastic du 20 octobre 2026, et la version v0.2.0 d’OpenSearch, du 25 mai 2025.
  • Leur documentation publique de l’API et, là où aucune n’en dit assez, les serveurs eux-mêmes, mesurés contre Elasticsearch 9.5 et OpenSearch 3.9.
  • Kibana, OpenSearch Dashboards et les clients officiels, dans n’importe quel langage, n’ont pas été ouverts.

Ce qu’il parle

  • L’API REST en HTTP ou HTTPS sur URLSession d’Apple, sans aucune dépendance ajoutée, pour Elasticsearch 8.18 et suivantes et OpenSearch 2.19 et suivantes.
  • La connexion par utilisateur et mot de passe ou, dans Elasticsearch, par clé d’API ; et GET / à la connexion, dont la réponse dit à Calíope auquel des deux il parle.
  • TLS avec votre propre autorité de certification et un certificat client facultatif ; désactiver la vérification seulement par un choix explicite de votre part, avec un avertissement visible ; et tunnel SSH.
  • Query DSL, et les langages de table de chaque produit : SQL dans les deux, ES|QL dans Elasticsearch, PPL dans OpenSearch.
  • Restaurer un instantané depuis Instantanés, avec Restaurer : les index que vous choisissez, sous un autre nom si vous le voulez (rename_pattern), et l’état global du cluster seulement si vous le demandez.

Ce qu’il ne parle pas

  • Ce qui relève de Kibana ou d’OpenSearch Dashboards : tableaux de bord, visualisations, Discover et alertes.
  • Réindexer, modifier les politiques de cycle de vie, les modèles ou les pipelines, et la réplication entre clusters : Calíope les montre et laisse leur modification au serveur.
  • L’apprentissage automatique et la recherche vectorielle par similarité : les champs vectoriels sont affichés, pas interrogés.
  • Les fonctions qui exigent une licence payante.