Icona dell'app Calíope

I driver che scrivo

Sei client, ciascuno scritto dalla specifica che pubblicano i suoi autori.

Calíope parla con sei tipi di server attraverso client che ho scritto io. Ciascuno nasce dalla documentazione che pubblicano i suoi autori, non dal codice di un altro client, e ciascuno implementa ciò che Calíope usa e niente di più. Questa pagina li riassume in tre parti: da cosa è stato scritto, cosa parla e cosa lascia fuori di proposito, con il motivo.

Dietro ogni riassunto c’è una specifica completa: ogni messaggio, ogni metodo di autenticazione, com’è fatto il client e come viene provato contro server reali. Vive nel repository del codice, in spagnolo, e a ogni commit viene verificata contro il codice che descrive: quando un driver cambia, il suo documento va riletto prima che la modifica entri.

MySQL e MariaDB

Scritto da

Cosa parla

  • La fase di connessione con la negoziazione delle capacità, e il TLS che parte a metà di essa.
  • L’autenticazione con mysql_native_password, caching_sha2_password, client_ed25519, parsec e mysql_clear_password, quest’ultima solo via TLS.
  • Le query di testo (COM_QUERY) con più risultati per risposta, così una CALL restituisce le sue righe.
  • I prepared statement (COM_STMT_PREPARE, COM_STMT_EXECUTE, COM_STMT_CLOSE) con righe binarie: i valori viaggiano separati dall’SQL.
  • LOCAL INFILE, che invia solo il file che scegli.
  • Le righe interessate, l’ultimo id inserito, gli avvisi e lo stato della transazione, come li riporta il server nella sua risposta.
  • L’arresto di una query in corso con KILL QUERY da una seconda connessione.

Cosa non parla

  • CLIENT_MULTI_STATEMENTS: mai dichiarato. L’editor invia un’istruzione alla volta, e senza di esso un testo iniettato non può accodare una seconda istruzione.
  • La compressione e il protocollo X (porta 33060): nessuno strumento ne ha bisogno.
  • I cursori lato server: i risultati grandi arrivano riga per riga.
  • La replica, COM_CHANGE_USER e i comandi del binlog: nessuno strumento li usa.
  • Altri metodi di autenticazione (sha256_password, Kerberos, LDAP SASL, GSSAPI): rifiutati con il nome del metodo, così l’errore dice cosa manca.
  • Una password in chiaro su una connessione non cifrata: mai.
  • I server anteriori a MySQL 4.1.

PostgreSQL

Scritto da

Cosa parla

  • Il TLS chiesto prima di tutto; se il server lo rifiuta, nulla parte in chiaro.
  • L’autenticazione con SCRAM-SHA-256, md5 o password in chiaro, quest’ultima solo via TLS.
  • La query semplice e quella estesa (Parse, Bind, Execute), con i parametri separati dall’SQL.
  • Ogni valore come testo, lo stesso che mostra psql, consegnato riga per riga man mano che arriva.
  • Le righe interessate, gli errori e gli avvisi con tutti i loro campi, e lo stato della transazione a ogni risposta.
  • L’annullamento con CancelRequest e la chiave che il server consegna alla connessione, e DISCARD ALL prima che una connessione torni nel pool.

Cosa non parla

  • COPY: Calíope non lo invia mai; uno scritto nell’editor chiude la connessione, perché il server aspetterebbe dati che non arriveranno.
  • LISTEN/NOTIFY: le notifiche vengono lette e scartate.
  • Kerberos (GSSAPI) e SSPI: richiedono ticket di sistema che la sandbox non dà.
  • SCRAM con channel binding (SCRAM-SHA-256-PLUS): il server non può esigerlo, quindi non cambia chi entra.
  • I risultati in binario, i cursori con nome, i prepared statement con nome e il pipelining: una richiesta in volo per connessione.
  • Il protocollo di replica e la chiamata di funzioni.
  • Una password in chiaro su una connessione non cifrata: mai.

MongoDB

Scritto da

Cosa parla

  • BSON, tipo per tipo, Decimal128 compreso.
  • OP_MSG e l’handshake hello, con MongoDB 4.0 o successivo.
  • L’autenticazione con SCRAM-SHA-256 e SCRAM-SHA-1.
  • TLS con la stessa politica degli altri motori.
  • Le stringhe di connessione mongodb:// e mongodb+srv://, con i record SRV e TXT risolti dal DNS di sistema.
  • Il primario di un replica set, letto dalla risposta a hello, e un pool di connessioni.

Cosa non parla

  • Qualsiasi messaggio diverso da OP_MSG: un server che parla solo quelli vecchi è anteriore alla 4.0 e viene rifiutato.
  • La compressione e i cursori exhaust: ogni comando aspetta la sua risposta.
  • Le sessioni, le transazioni, i change stream, le scritture ripetibili e la lettura dai secondari: gli strumenti non li usano, e tutto va al primario.
  • I metodi di autenticazione che non sono SCRAM (x.509, Kerberos, LDAP, AWS, OIDC): l’errore dice quelli che offre il server.
  • I tipi BSON obsoleti: letti e mostrati come non supportati, mai scritti.
  • Le opzioni di file della stringa (tlsCAFile): la sandbox non lascia leggere un percorso, quindi i certificati vanno nel profilo.
  • Un nome mongodb+srv:// attraverso un tunnel SSH: lo risolverebbe l’altro capo, non il tuo dispositivo.

Redis

Scritto da

Cosa parla

  • RESP2 e RESP3, tutti i tipi, con ogni risposta abbinata al suo comando per posizione.
  • L’autenticazione con HELLO o AUTH, con un utente ACL e la sua password.
  • SELECT applicato a ogni connessione quando viene prestata, e TLS con la stessa politica degli altri motori.
  • La modalità cluster: i 16.384 slot, la mappa riletta dopo un MOVED, un ASK valido una volta sola.
  • Una console che controlla ogni comando che scrivi contro una lista prima che arrivi al server.

Cosa non parla

  • La forma «inline» dei comandi: non può portare byte arbitrari.
  • Pub/sub e MONITOR: niente nel client si iscrive.
  • Le transazioni (MULTI, WATCH), i comandi bloccanti senza limite, CLIENT REPLY OFF, RESET e i comandi di replica: una connessione del pool è condivisa da tutti gli strumenti, e ci lascerebbero uno stato.
  • La cache lato client e la scoperta tramite Sentinel: il client si collega all’indirizzo del profilo.
  • Un cluster attraverso un tunnel SSH: i nodi annunciano indirizzi che il tunnel non raggiunge, quindi viene rifiutato prima di collegarsi.

SQL Server (TDS)

Scritto da

Cosa parla

  • Sempre cifrato: prima la modalità rigorosa di TDS 8.0, TLS dal primo byte con TLS 1.2 o successivo, e l’handshake di TDS 7.x dentro il PRELOGIN quando il server non offre la modalità rigorosa.
  • PRELOGIN e LOGIN7 (TDS 7.4) con un accesso di SQL Server.
  • I batch (SQL_BATCH) e le query parametrizzate via RPC a sp_executesql, con valori tipizzati separati dall’SQL.
  • Il flusso di token: colonne, righe, conteggi, errori, messaggi e cambi d’ambiente, e i tipi di SQL Server, spaziali compresi.
  • L’annullamento con ATTENTION, e RESETCONNECTION prima che una connessione torni nel pool.
  • GO come separatore di batch, gestito dal client come fanno gli strumenti di SQL Server.

Cosa non parla

  • MARS: una richiesta per connessione, e una connessione per ogni utente del pool.
  • L’autenticazione integrata di Windows (SSPI, Kerberos, NTLM): richiede un dominio e un client Kerberos che la sandbox non ha.
  • Microsoft Entra ID: è un flusso OAuth verso Microsoft, un prodotto a parte.
  • Le connessioni non cifrate, o che cifrerebbero solo l’accesso: rifiutate.
  • Il caricamento massivo, le richieste al gestore delle transazioni e l’instradamento di Always On: le transazioni viaggiano come T-SQL, i caricamenti come INSERT.
  • text, ntext, image, hierarchyid e i tipi CLR utente: mostrati come non supportati.

ClickHouse (HTTP)

Scritto da

  • La documentazione di ClickHouse sulla sua interfaccia HTTP, i suoi formati e impostazioni, la sintassi dei parametri di query e le sue tabelle di sistema.
  • RFC 3986, per codificare la query string.
  • E il server stesso, che descrive impostazioni, funzioni e tipi nelle sue tabelle system.

Cosa parla

  • HTTP o HTTPS su URLSession di Apple, senza dipendenze aggiunte: un’istruzione per richiesta, il database in ogni richiesta.
  • I parametri di query tipizzati ({nome:Tipo}): i valori viaggiano separati dall’SQL.
  • I risultati letti riga per riga a query finita, così un errore alla fine di un 200 OK viene colto.
  • Un tetto alle righe restituite, scritto accanto alla cifra che limita.
  • Una sessione solo per un batch che ne ha bisogno, l’avanzamento da system.processes e l’arresto con KILL QUERY.
  • TLS con le stesse tre scelte degli altri motori; attraverso un tunnel SSH il certificato viene comunque verificato contro l’host del profilo.

Cosa non parla

  • Il protocollo nativo su TCP (porta 9000) e il suo formato: l’interfaccia HTTP dà ciò che serve a Calíope senza un protocollo binario né una dipendenza.
  • gRPC e le interfacce che imitano MySQL o PostgreSQL.
  • Più istruzioni per richiesta, o una sessione per tab: il server rifiuta due richieste contemporanee sulla stessa sessione.
  • I dati nel corpo della richiesta e le tabelle esterne: gli insert dell’app viaggiano come SQL.
  • I certificati client: un profilo che li porta viene rifiutato.
  • Le transazioni: il server non le ha.