Icona dell'app Calíope

I driver che scrivo

Nove client, ciascuno scritto da ciò che pubblicano i suoi autori.

Calíope parla con otto tipi di server attraverso client che ho scritto io. Ciascuno nasce da ciò che pubblicano i suoi autori: la loro specifica e la loro documentazione o, dove non pubblicano alcuna specifica, come Oracle, il driver che indicano come riferimento; mai dal client di qualcun altro. 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.

Anche TiDB

  • TiDB parla questo stesso protocollo, quindi passa per questo stesso client, misurato contro TiDB 8.5. Il suo saluto porta 8.0.11-TiDB-v8.5.8, ed è quella stringa di versione a dire a Calíope che sta parlando con TiDB, qualunque cosa dica il profilo.
  • L’id di una connessione TiDB può essere di 64 bit mentre il saluto ne porta solo i 32 bassi, e un KILL QUERY con quelli non ferma nulla: con TiDB chiedo CONNECTION_ID() una volta per connessione e annullo con l’id intero.
  • I metodi di accesso propri di TiDB (tidb_sm3_password, tidb_auth_token): non parlati, e rifiutati con il nome del metodo, come qualsiasi altro.
  • La sua porta di stato (10080) e le sue metriche Prometheus: una seconda porta che bisognerebbe aprire e far passare nel tunnel. Si mostra ciò che dà la connessione SQL, e il resto dice n/a.

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.
  • Un Sentinel, aperto dal suo profilo: Topologia mostra i primari che sorveglia, le loro repliche e gli altri sentinel, così come li riporta (SENTINEL MASTERS, REPLICAS, SENTINELS).

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 seguire Sentinel fino al nodo che è primario in quel momento: 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.

Anche Valkey

  • Valkey parla RESP2 e RESP3 come Redis, quindi passa per questo stesso client, misurato contro Valkey 8.0 e 9.1, singolo e in cluster con slot in migrazione. HELLO risponde server valkey, ed è questo a dire a Calíope con quale dei due sta parlando.
  • Valkey non pubblica redis_mode:: senza HELLO, la modalità si legge da server_mode: in INFO server.
  • Ciò che Valkey aggiunge sopra (COMMANDLOG, database numerati dentro un cluster): non parlato. SLOWLOG esiste ancora, ed è ciò che legge Comandi lenti.

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.

Oracle Database (TNS)

Scritto da

  • Oracle non pubblica la specifica del suo protocollo di rete. Ciò che pubblica, e indica come riferimento pubblico, è il codice della modalità thin del suo driver Python, python-oracledb, sotto la Universal Permissive License 1.0 o la Apache License 2.0. Scrivo da lì com’era il 6 ottobre 2026, a una revisione fissa; ogni file che ne deriva lo dice, e la sua licenza viaggia con gli altri avvisi di terze parti di Calíope.
  • La documentazione di Oracle: la SQL Language Reference, la Database Reference per le viste del dizionario, il riferimento dei package PL/SQL e la Net Services Reference.
  • Gli altri client di Oracle, in qualsiasi linguaggio, non sono stati aperti.

Cosa parla

  • TNS su TCP, o su TLS (TCPS) verificato contro i certificati del sistema o quello che porta il profilo, con il nome verificato comunque rispetto all’host del profilo, anche attraverso un tunnel SSH, e i reindirizzamenti del listener.
  • L’accesso con la password del database (O5LOGON).
  • Le istruzioni con valori tipizzati separati dall’SQL, e le righe a blocchi; CLOB e BLOB si leggono interi fino a un tetto, e oltre la cella ne dice la dimensione.
  • L’annullamento di un’istruzione in corso.

Cosa non parla

  • L’interruzione fuori banda: SwiftNIO non può inviarla, quindi annullare viaggia sempre nella banda.
  • Il wallet e i certificati client, i token di accesso, Kerberos e l’autenticazione del sistema operativo: si entra con la password, e con TLS in una sola direzione, e un profilo con un certificato client viene rifiutato.
  • Decodificare i tipi oggetto, le collezioni, XMLTYPE, il JSON binario, VECTOR e BFILE: la cella ne dice il tipo al loro posto.
  • DRCP, il pool di sessioni proprio del driver, il pipelining e l’autenticazione rapida.
  • Advanced Queuing, il commit a due fasi, il caricamento in percorso diretto e le notifiche di modifica.
  • tnsnames.ora e sqlnet.ora: il profilo porta l’host, la porta e il servizio.

Apache Cassandra e ScyllaDB (CQL)

Scritto da

  • La specifica del protocollo nativo v4 che pubblica il progetto Apache Cassandra, a una revisione fissa del 3 aprile 2025.
  • Ciò che ScyllaDB aggiunge al protocollo e Calíope legge, le chiavi SCYLLA_* di SUPPORTED, misurato contro il server.
  • Gli altri client di Cassandra, in qualunque linguaggio, non sono stati aperti.

Cosa parla

  • La versione 4 del protocollo nativo, quella che parlano Cassandra 4.1 e successive e ScyllaDB 2025.1 e successive, con ogni risposta abbinata alla sua richiesta tramite il suo stream.
  • L’accesso con password (SASL PLAIN contro PasswordAuthenticator), TLS con certificato client facoltativo e tunnel SSH.
  • Query con livello di consistenza, paginazione tramite paging_state, istruzioni preparate per i valori, batch logged e unlogged, e traccia su richiesta.
  • Tutti i tipi CQL, scritti come li scrive cqlsh.
  • Un solo driver per i due server: OPTIONS riceve risposta prima dell’accesso, e le chiavi SCYLLA_* di quella risposta dicono a Calíope con quale dei due sta parlando.

Cosa non parla

  • La versione 5 del protocollo e successive: la 4 è quella che parlano i due server in tutte le versioni che Calíope supporta.
  • La compressione, e REGISTER con i suoi eventi: a un client desktop non servono.
  • L’instradamento per token: il client parla con il punto di contatto del profilo, o con il suo alternativo.
  • L’accesso con Kerberos e LDAP.

Elasticsearch e OpenSearch (REST)

Scritto da

  • La specifica dell’API REST che pubblica Elastic, e quella che pubblica il progetto OpenSearch, entrambe a una revisione fissa: quella di Elastic del 20 ottobre 2026 e la versione v0.2.0 di OpenSearch, del 25 maggio 2025.
  • La loro documentazione pubblica dell’API e, dove nessuna dice abbastanza, i server stessi, misurati contro Elasticsearch 9.5 e OpenSearch 3.9.
  • Kibana, OpenSearch Dashboards e i client ufficiali, in qualunque linguaggio, non sono stati aperti.

Cosa parla

  • L’API REST via HTTP o HTTPS su URLSession di Apple, senza alcuna dipendenza aggiunta, per Elasticsearch 8.18 e successive e OpenSearch 2.19 e successive.
  • L’accesso con utente e password o, in Elasticsearch, con chiave API; e GET / alla connessione, la cui risposta dice a Calíope con quale dei due sta parlando.
  • TLS con la tua autorità di certificazione e certificato client facoltativo; disattivare la verifica solo come tua scelta esplicita, con un avviso visibile; e tunnel SSH.
  • Query DSL, e i linguaggi tabellari di ciascun prodotto: SQL in entrambi, ES|QL in Elasticsearch, PPL in OpenSearch.
  • Ripristinare uno snapshot da Snapshot, con Ripristina: gli indici che scegli, con un altro nome se vuoi (rename_pattern), e lo stato globale del cluster solo se lo chiedi.

Cosa non parla

  • Ciò che appartiene a Kibana o a OpenSearch Dashboards: dashboard, visualizzazioni, Discover e avvisi.
  • Reindicizzare, modificare le politiche di ciclo di vita, i modelli o le pipeline, e la replica tra cluster: Calíope li mostra e lascia la modifica al server.
  • Il machine learning e la ricerca vettoriale per similarità: i campi vettoriali si mostrano, non si interrogano.
  • Le funzioni che richiedono una licenza a pagamento.