Icône de l'app Calíope

Les pilotes que j’écris

Six clients, chacun écrit d’après la spécification que publient ses auteurs.

Calíope parle à six sortes de serveurs par des clients que j’ai écrits moi-même. Chacun vient de la documentation que publient ses auteurs, pas du code d’un autre client, 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.

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.

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 la découverte par Sentinel : 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.

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.