Symbol der App Calíope

Die Treiber, die ich schreibe

Sechs Clients, jeder nach der Spezifikation geschrieben, die seine Hersteller veröffentlichen.

Calíope spricht mit sechs Arten von Servern über Clients, die ich selbst geschrieben habe. Jeder stammt aus der Dokumentation, die seine Hersteller veröffentlichen, nicht aus dem Code eines anderen Clients, und jeder implementiert, was Calíope braucht, und nichts mehr. Diese Seite fasst jeden in drei Teilen zusammen: wonach er geschrieben ist, was er spricht und was er bewusst weglässt, mit dem Grund.

Hinter jeder Zusammenfassung steht eine vollständige Spezifikation: jede Nachricht, jede Anmeldemethode, wie der Client gebaut ist und wie er gegen echte Server getestet wird. Sie liegt im Quellcode-Repository, auf Spanisch, und wird bei jedem Commit gegen den Code geprüft, den sie beschreibt: Ändert sich ein Treiber, muss sein Dokument neu gelesen werden, bevor die Änderung hineinkommt.

MySQL und MariaDB

Geschrieben nach

Was er spricht

  • Die Verbindungsphase mit der Aushandlung der Fähigkeiten, und TLS, das mittendrin beginnt.
  • Die Anmeldung mit mysql_native_password, caching_sha2_password, client_ed25519, parsec und mysql_clear_password, Letzteres nur über TLS.
  • Textabfragen (COM_QUERY) mit mehreren Ergebnissen pro Antwort, sodass ein CALL seine Zeilen liefert.
  • Prepared Statements (COM_STMT_PREPARE, COM_STMT_EXECUTE, COM_STMT_CLOSE) mit binären Zeilen: Die Werte reisen getrennt vom SQL.
  • LOCAL INFILE, das nur die Datei sendet, die du auswählst.
  • Betroffene Zeilen, die letzte eingefügte ID, Warnungen und den Transaktionsstatus, so wie der Server sie in seiner eigenen Antwort meldet.
  • Das Anhalten einer laufenden Abfrage mit KILL QUERY über eine zweite Verbindung.

Was er nicht spricht

  • CLIENT_MULTI_STATEMENTS: wird nie deklariert. Der Editor sendet eine Anweisung nach der anderen, und ohne diese Fähigkeit kann eingeschleuster Text keine zweite Anweisung anhängen.
  • Kompression und das X-Protokoll (Port 33060): Kein Werkzeug braucht sie.
  • Serverseitige Cursor: Große Ergebnisse kommen stattdessen Zeile für Zeile.
  • Replikation, COM_CHANGE_USER und die Binlog-Befehle: Kein Werkzeug nutzt sie.
  • Andere Anmeldemethoden (sha256_password, Kerberos, LDAP SASL, GSSAPI): werden mit dem Namen der Methode abgelehnt, sodass der Fehler sagt, was fehlt.
  • Ein Klartext-Passwort über eine unverschlüsselte Verbindung: niemals.
  • Server vor MySQL 4.1.

PostgreSQL

Geschrieben nach

Was er spricht

  • TLS wird vor allem anderen angefragt; lehnt der Server ab, geht nichts im Klartext hinaus.
  • Die Anmeldung mit SCRAM-SHA-256, md5 oder Klartext-Passwort, Letzteres nur über TLS.
  • Die einfache und die erweiterte Abfrage (Parse, Bind, Execute), mit den Parametern getrennt vom SQL.
  • Jeder Wert als Text, derselbe, den psql zeigt, Zeile für Zeile geliefert, sobald er ankommt.
  • Betroffene Zeilen, Fehler und Hinweise mit allen ihren Feldern, und der Transaktionsstatus mit jeder Antwort.
  • Das Abbrechen mit CancelRequest und dem Schlüssel, den der Server bei der Anmeldung übergibt, und DISCARD ALL, bevor eine Verbindung in den Pool zurückgeht.

Was er nicht spricht

  • COPY: Calíope sendet es nie; ein im Editor getipptes schließt die Verbindung, weil der Server auf Daten warten würde, die nie kommen.
  • LISTEN/NOTIFY: Benachrichtigungen werden gelesen und verworfen.
  • Kerberos (GSSAPI) und SSPI: Sie brauchen System-Tickets, die die Sandbox nicht gibt.
  • SCRAM mit Kanalbindung (SCRAM-SHA-256-PLUS): Der Server kann sie nicht verlangen, also ändert sie nichts daran, wer hineinkommt.
  • Binäre Ergebnisse, benannte Cursor, benannte Prepared Statements und Pipelining: eine Anfrage unterwegs pro Verbindung.
  • Das Replikationsprotokoll und Funktionsaufrufe.
  • Ein Klartext-Passwort über eine unverschlüsselte Verbindung: niemals.

MongoDB

Geschrieben nach

Was er spricht

  • BSON, Typ für Typ, einschließlich Decimal128.
  • OP_MSG und der hello-Handshake, mit MongoDB 4.0 oder neuer.
  • Die Anmeldung mit SCRAM-SHA-256 und SCRAM-SHA-1.
  • TLS mit derselben Richtlinie wie bei allen anderen Engines.
  • Connection Strings, mongodb:// und mongodb+srv://, mit den SRV- und TXT-Einträgen über das DNS des Systems.
  • Der Primary eines Replica Sets, aus der Antwort auf hello gelesen, und ein Verbindungspool.

Was er nicht spricht

  • Jede Nachricht außer OP_MSG: Ein Server, der nur die alten spricht, ist älter als 4.0 und wird abgelehnt.
  • Kompression und Exhaust-Cursor: Jeder Befehl wartet auf seine Antwort.
  • Sessions, Transaktionen, Change Streams, wiederholbare Schreibvorgänge und das Lesen von Secondaries: Die Werkzeuge nutzen sie nicht, und alles geht an den Primary.
  • Anmeldemethoden, die nicht SCRAM sind (x.509, Kerberos, LDAP, AWS, OIDC): Der Fehler nennt, was der Server anbietet.
  • Veraltete BSON-Typen: werden gelesen und als nicht unterstützt angezeigt, nie geschrieben.
  • Dateioptionen im Connection String (tlsCAFile): Die Sandbox lässt die App keinen Pfad lesen, also gehören die Zertifikate ins Profil.
  • Ein mongodb+srv://-Name durch einen SSH-Tunnel: Das andere Ende würde ihn auflösen, nicht dein Gerät.

Redis

Geschrieben nach

Was er spricht

  • RESP2 und RESP3, alle Typen, jede Antwort ihrem Befehl über die Position zugeordnet.
  • Die Anmeldung mit HELLO oder AUTH, mit einem ACL-Benutzer und seinem Passwort.
  • SELECT, auf jede Verbindung angewendet, wenn sie verliehen wird, und TLS mit derselben Richtlinie wie bei allen anderen Engines.
  • Der Cluster-Modus: die 16.384 Slots, eine neu gelesene Karte nach MOVED, ein einmaliges ASK.
  • Eine Konsole, die jeden Befehl, den du tippst, gegen eine Liste prüft, bevor er den Server erreicht.

Was er nicht spricht

  • Die Inline-Form der Befehle: Sie kann keine beliebigen Bytes tragen.
  • Pub/Sub und MONITOR: Nichts im Client abonniert.
  • Transaktionen (MULTI, WATCH), blockierende Befehle ohne Zeitlimit, CLIENT REPLY OFF, RESET und Replikationsbefehle: Eine Verbindung aus dem Pool teilen sich alle Werkzeuge, und sie würden Zustand darauf hinterlassen.
  • Clientseitiges Caching und die Erkennung über Sentinel: Der Client verbindet sich mit der Adresse im Profil.
  • Ein Cluster durch einen SSH-Tunnel: Die Knoten melden Adressen, die der Tunnel nicht erreicht, also wird er vor dem Verbinden abgelehnt.

SQL Server (TDS)

Geschrieben nach

Was er spricht

  • Immer verschlüsselt: zuerst der strenge Modus von TDS 8.0, TLS ab dem ersten Byte mit TLS 1.2 oder neuer, und der Handshake von TDS 7.x im PRELOGIN, wenn der Server den strengen Modus nicht anbietet.
  • PRELOGIN und LOGIN7 (TDS 7.4) mit einer SQL-Server-Anmeldung.
  • Batches (SQL_BATCH) und parametrisierte Abfragen über RPC an sp_executesql, mit typisierten Werten getrennt vom SQL.
  • Der Token-Strom: Spalten, Zeilen, Zeilenzahlen, Fehler, Meldungen und Umgebungsänderungen, und die Typen von SQL Server, räumliche eingeschlossen.
  • Das Abbrechen mit ATTENTION, und RESETCONNECTION, bevor eine Verbindung in den Pool zurückgeht.
  • GO als Batch-Trenner, vom Client behandelt wie von den Werkzeugen von SQL Server.

Was er nicht spricht

  • MARS: eine Anfrage pro Verbindung, und eine Verbindung pro Nutzer des Pools.
  • Die integrierte Windows-Authentifizierung (SSPI, Kerberos, NTLM): Sie braucht eine Domäne und einen Kerberos-Client, die die Sandbox nicht hat.
  • Microsoft Entra ID: ein OAuth-Ablauf gegen Microsoft, ein eigenes Produkt.
  • Unverschlüsselte Verbindungen, oder solche, die nur die Anmeldung verschlüsseln würden: werden abgelehnt.
  • Massenladen, Anfragen an den Transaktionsmanager und das Routing von Always On: Transaktionen reisen als T-SQL, Ladevorgänge als INSERT.
  • text, ntext, image, hierarchyid und benutzerdefinierte CLR-Typen: werden als nicht unterstützt angezeigt.

ClickHouse (HTTP)

Geschrieben nach

  • Die ClickHouse-Dokumentation zu ihrer HTTP-Schnittstelle, ihren Formaten und Einstellungen, der Syntax der Abfrageparameter und ihren Systemtabellen.
  • RFC 3986 für die Kodierung des Query-Strings.
  • Und der Server selbst, der seine Einstellungen, Funktionen und Typen in seinen eigenen system-Tabellen beschreibt.

Was er spricht

  • HTTP oder HTTPS auf Apples URLSession, ohne zusätzliche Abhängigkeit: eine Anweisung pro Anfrage, die Datenbank in jeder Anfrage.
  • Typisierte Abfrageparameter ({name:Typ}): Die Werte reisen getrennt vom SQL.
  • Ergebnisse werden Zeile für Zeile gelesen, sobald die Abfrage fertig ist, sodass ein Fehler am Ende eines 200 OK erkannt wird.
  • Eine Obergrenze für zurückgegebene Zeilen, neben der Zahl angegeben, die sie begrenzt.
  • Eine Session nur für einen Batch, der eine braucht, der Fortschritt aus system.processes und das Anhalten mit KILL QUERY.
  • TLS mit denselben drei Optionen wie bei den anderen Engines; durch einen SSH-Tunnel wird das Zertifikat weiterhin gegen den Host des Profils geprüft.

Was er nicht spricht

  • Das native TCP-Protokoll (Port 9000) und sein Format: Die HTTP-Schnittstelle liefert, was Calíope braucht, ohne binäres Protokoll und ohne Abhängigkeit.
  • gRPC und die Schnittstellen, die MySQL oder PostgreSQL nachahmen.
  • Mehrere Anweisungen pro Anfrage, oder eine Session pro Tab: Der Server lehnt zwei gleichzeitige Anfragen auf einer Session ab.
  • Daten im Body der Anfrage und externe Tabellen: Die Inserts der App reisen als SQL.
  • Client-Zertifikate: Ein Profil, das sie mitbringt, wird abgelehnt.
  • Transaktionen: Der Server hat keine.