Ícono de la app Calíope

Los drivers que escribo

Nueve clientes, cada uno escrito desde lo que publican sus autores.

Calíope habla con ocho clases de servidor mediante clientes que escribí yo. Cada uno salió de lo que publican sus autores: su especificación y su documentación o, donde no publican especificación, como Oracle, el driver que señalan como referencia; nunca del cliente de otro. Y cada uno implementa lo que Calíope usa y nada más. Esta página los resume en tres partes: de qué se escribió, qué habla y qué deja fuera a propósito, con el motivo.

Detrás de cada resumen hay una especificación completa: cada mensaje, cada método de autenticación, cómo está hecho el cliente y cómo se prueba contra servidores reales. Vive en el repositorio del código, en español, y en cada commit se comprueba contra el código que describe: cuando un driver cambia, su documento se vuelve a leer antes de que el cambio entre.

MySQL y MariaDB

De qué se escribió

Qué habla

  • La fase de conexión con la negociación de capacidades, y el TLS que empieza a mitad de ella.
  • La autenticación con mysql_native_password, caching_sha2_password, client_ed25519, parsec y mysql_clear_password, ésta sólo por TLS.
  • Las consultas de texto (COM_QUERY) con varios resultados por respuesta, así que un CALL devuelve sus filas.
  • Las sentencias preparadas (COM_STMT_PREPARE, COM_STMT_EXECUTE, COM_STMT_CLOSE) con filas binarias: los valores viajan aparte del SQL.
  • LOCAL INFILE, que manda sólo el archivo que eliges.
  • Las filas afectadas, el último id insertado, los avisos y el estado de la transacción, tal como los da el servidor en su propia respuesta.
  • Detener una consulta en curso con KILL QUERY desde una segunda conexión.

Qué no habla

  • CLIENT_MULTI_STATEMENTS: no se declara nunca. El editor manda una sentencia cada vez, y sin él un texto inyectado no puede encadenar una segunda sentencia.
  • La compresión y el protocolo X (puerto 33060): ninguna herramienta los necesita.
  • Los cursores del lado del servidor: los resultados grandes llegan fila a fila.
  • La replicación, COM_CHANGE_USER y los comandos del binlog: ninguna herramienta los usa.
  • Otros métodos de autenticación (sha256_password, Kerberos, LDAP SASL, GSSAPI): se rechazan con el nombre del método, así que el error dice qué falta.
  • Una contraseña en claro por una conexión sin cifrar: nunca.
  • Los servidores anteriores a MySQL 4.1.

También TiDB

  • TiDB habla este mismo protocolo, así que va por este mismo cliente, medido contra TiDB 8.5. Su saludo trae 8.0.11-TiDB-v8.5.8, y esa cadena de versión es lo que le dice a Calíope que habla con TiDB, diga lo que diga el perfil.
  • El id de una conexión de TiDB puede tener 64 bits y el saludo trae sólo los 32 de abajo, y un KILL QUERY con ésos no detiene nada: con TiDB pregunto CONNECTION_ID() una vez por conexión y cancelo con el id entero.
  • Los métodos de acceso propios de TiDB (tidb_sm3_password, tidb_auth_token): no se hablan, y se rechazan con el nombre del método, como cualquier otro.
  • Su puerto de estado (10080) y sus métricas de Prometheus: un segundo puerto que habría que abrir y llevar por el túnel. Se enseña lo que da la conexión SQL, y lo demás dice n/a.

PostgreSQL

De qué se escribió

Qué habla

  • El TLS se pide antes que nada; si el servidor lo rechaza, no se manda nada en claro.
  • La autenticación con SCRAM-SHA-256, md5 o contraseña en claro, ésta sólo por TLS.
  • La consulta simple y la extendida (Parse, Bind, Execute), con los parámetros aparte del SQL.
  • Cada valor en texto, el mismo que enseña psql, entregado fila a fila conforme llega.
  • Las filas afectadas, los errores y avisos con todos sus campos, y el estado de la transacción en cada respuesta.
  • La cancelación con CancelRequest y la clave que el servidor entrega al conectar, y DISCARD ALL antes de que una conexión vuelva al pool.

Qué no habla

  • COPY: Calíope no lo manda nunca; uno escrito en el editor cierra la conexión, porque el servidor esperaría datos que no van a llegar.
  • LISTEN/NOTIFY: las notificaciones se leen y se descartan.
  • Kerberos (GSSAPI) y SSPI: necesitan tickets del sistema que el sandbox no da.
  • SCRAM con vinculación al canal (SCRAM-SHA-256-PLUS): el servidor no puede exigirla, así que no cambia quién entra.
  • Los resultados en binario, los cursores con nombre, las sentencias preparadas con nombre y el pipelining: una petición en vuelo por conexión.
  • El protocolo de replicación y la llamada a funciones.
  • Una contraseña en claro por una conexión sin cifrar: nunca.

MongoDB

De qué se escribió

Qué habla

  • BSON, tipo a tipo, Decimal128 incluido.
  • OP_MSG y el saludo hello, con MongoDB 4.0 o posterior.
  • La autenticación con SCRAM-SHA-256 y SCRAM-SHA-1.
  • TLS con la misma política que el resto de motores.
  • Las cadenas de conexión mongodb:// y mongodb+srv://, con los registros SRV y TXT resueltos por el DNS del sistema.
  • El primario de un conjunto de réplicas, leído de la respuesta a hello, y un pool de conexiones.

Qué no habla

  • Cualquier mensaje que no sea OP_MSG: un servidor que sólo habla los heredados es anterior a la 4.0 y se rechaza.
  • La compresión y los cursores exhaust: cada orden espera su respuesta.
  • Las sesiones, las transacciones, los change streams, las escrituras reintentables y la lectura de secundarios: las herramientas no los usan, y todo va al primario.
  • Los métodos de autenticación que no son SCRAM (x.509, Kerberos, LDAP, AWS, OIDC): el error dice cuáles ofrece el servidor.
  • Los tipos BSON obsoletos: se leen y se enseñan como no admitidos, y no se escriben.
  • Las opciones de archivo de la cadena (tlsCAFile): el sandbox no deja leer una ruta, así que los certificados van en el perfil.
  • Un nombre mongodb+srv:// por un túnel SSH: lo resolvería el otro extremo, no tu aparato.

Redis

De qué se escribió

Qué habla

  • RESP2 y RESP3, todos los tipos, con cada respuesta casada con su comando por posición.
  • La autenticación con HELLO o AUTH, con un usuario de ACL y su contraseña.
  • SELECT aplicado a cada conexión al prestarla, y TLS con la misma política que el resto de motores.
  • El modo clúster: las 16.384 ranuras, el mapa releído tras un MOVED y un ASK que vale una sola vez.
  • Una consola que comprueba cada comando que escribes contra una lista antes de que llegue al servidor.
  • Un Sentinel, abierto desde su propio perfil: Topología enseña los primarios que vigila, sus réplicas y los demás centinelas, tal como él los cuenta (SENTINEL MASTERS, REPLICAS, SENTINELS).

Qué no habla

  • La forma «inline» de los comandos: no admite bytes arbitrarios.
  • Pub/sub y MONITOR: nada del cliente se suscribe.
  • Las transacciones (MULTI, WATCH), los comandos bloqueantes sin tope, CLIENT REPLY OFF, RESET y los de replicación: una conexión del pool es de todas las herramientas, y dejarían estado en ella.
  • La caché del lado del cliente, y seguir a Sentinel hasta el nodo que sea primario en cada momento: el cliente se conecta a la dirección del perfil.
  • Un clúster por un túnel SSH: los nodos anuncian direcciones que el túnel no alcanza, así que se rechaza antes de conectar.

También Valkey

  • Valkey habla RESP2 y RESP3 como Redis, así que va por este mismo cliente, medido contra Valkey 8.0 y 9.1, suelto y en clúster con ranuras migrando. HELLO contesta server valkey, y eso es lo que le dice a Calíope con cuál de los dos habla.
  • Valkey no publica redis_mode:: sin HELLO, el modo se lee de server_mode: en INFO server.
  • Lo que Valkey suma encima (COMMANDLOG, bases numeradas dentro de un clúster): no se habla. SLOWLOG sigue existiendo, y es lo que lee Comandos lentos.

SQL Server (TDS)

De qué se escribió

Qué habla

  • Siempre cifrado: primero el modo estricto de TDS 8.0, TLS desde el primer byte con TLS 1.2 o posterior, y el saludo de TDS 7.x dentro del PRELOGIN cuando el servidor no ofrece el estricto.
  • PRELOGIN y LOGIN7 (TDS 7.4) con un inicio de sesión de SQL Server.
  • Los lotes (SQL_BATCH) y las consultas con parámetros por RPC a sp_executesql, con valores tipados aparte del SQL.
  • El flujo de tokens: columnas, filas, recuentos, errores, mensajes y cambios de entorno, y los tipos de SQL Server, los espaciales incluidos.
  • La cancelación con ATTENTION, y RESETCONNECTION antes de que una conexión vuelva al pool.
  • GO como separador de lotes, que resuelve el cliente como lo hacen las herramientas de SQL Server.

Qué no habla

  • MARS: una petición por conexión, y una conexión por cada usuario del pool.
  • La autenticación integrada de Windows (SSPI, Kerberos, NTLM): exige un dominio y un cliente Kerberos que el sandbox no tiene.
  • Microsoft Entra ID: es un flujo OAuth contra Microsoft, un producto aparte.
  • Las conexiones sin cifrar, o que cifrarían sólo el inicio de sesión: se rechazan.
  • La carga masiva, las peticiones al gestor de transacciones y el enrutado de Always On: las transacciones van como T-SQL y las cargas como INSERT.
  • text, ntext, image, hierarchyid y los tipos CLR de usuario: se enseñan como no admitidos.

ClickHouse (HTTP)

De qué se escribió

  • La documentación de ClickHouse sobre su interfaz HTTP, sus formatos y ajustes, la sintaxis de los parámetros de consulta y sus tablas del sistema.
  • RFC 3986, para codificar la cadena de consulta.
  • Y el propio servidor, que describe sus ajustes, funciones y tipos en sus tablas system.

Qué habla

  • HTTP o HTTPS sobre URLSession de Apple, sin ninguna dependencia añadida: una sentencia por petición, y la base en cada petición.
  • Los parámetros de consulta tipados ({nombre:Tipo}): los valores viajan aparte del SQL.
  • Los resultados se leen línea a línea cuando la consulta ha terminado, así que un error al final de un 200 OK no se escapa.
  • Un techo de filas devueltas, escrito al lado de la cifra que limita.
  • Una sesión sólo para un lote que la necesita, el progreso de system.processes y la detención con KILL QUERY.
  • TLS con las mismas tres opciones que los demás motores; por un túnel SSH el certificado se sigue comprobando contra el host del perfil.

Qué no habla

  • El protocolo nativo por TCP (puerto 9000) y su formato: la interfaz HTTP da lo que Calíope necesita sin un protocolo binario ni una dependencia.
  • gRPC y las interfaces que imitan a MySQL o a PostgreSQL.
  • Varias sentencias por petición, o una sesión por pestaña: el servidor rechaza dos peticiones a la vez en una sesión.
  • Los datos en el cuerpo de la petición y las tablas externas: las inserciones de la app viajan como SQL.
  • Los certificados de cliente: se rechaza el perfil que los trae.
  • Las transacciones: el servidor no las tiene.

Oracle Database (TNS)

De qué se escribió

  • Oracle no publica la especificación de su protocolo de red. Lo que sí publica, y señala como la referencia pública, es el código del modo thin de su propio driver de Python, python-oracledb, bajo la Universal Permissive License 1.0 o la Apache License 2.0. Escribo desde él tal como estaba el 6 de octubre de 2026, a una revisión fija; cada archivo que deriva de él lo dice, y su licencia viaja con los demás avisos de terceros de Calíope.
  • La documentación de Oracle: la SQL Language Reference, la Database Reference para las vistas del diccionario, la referencia de los paquetes de PL/SQL y la Net Services Reference.
  • Los demás clientes de Oracle, en cualquier lenguaje, no se abrieron.

Qué habla

  • TNS por TCP, o por TLS (TCPS) comprobado contra los certificados del sistema o el que lleve el perfil, con el nombre comprobado igualmente contra el host del perfil, también por un túnel SSH, y las redirecciones del listener.
  • El inicio de sesión con la contraseña de la base (O5LOGON).
  • Las sentencias con valores tipados aparte del SQL, y las filas por lotes; CLOB y BLOB se leen enteros hasta un techo, y por encima la celda dice su tamaño.
  • La cancelación de una sentencia en curso.

Qué no habla

  • La interrupción fuera de banda: SwiftNIO no puede mandarla, así que cancelar viaja siempre dentro de banda.
  • El wallet y los certificados de cliente, los tokens de acceso, Kerberos y la autenticación del sistema operativo: se entra con la contraseña, y con TLS en una dirección, y un perfil que lleve certificado de cliente se rechaza.
  • Decodificar los tipos de objeto, las colecciones, XMLTYPE, el JSON binario, VECTOR y BFILE: la celda dice el tipo en su lugar.
  • DRCP, el pool de sesiones propio del driver, el pipelining y la autenticación rápida.
  • Advanced Queuing, el commit en dos fases, la carga por ruta directa y las notificaciones de cambios.
  • tnsnames.ora y sqlnet.ora: el perfil lleva el host, el puerto y el servicio.

Apache Cassandra y ScyllaDB (CQL)

De qué se escribió

  • La especificación del protocolo nativo v4 que publica el proyecto Apache Cassandra, a una revisión fija del 3 de abril de 2025.
  • Lo que ScyllaDB añade al protocolo y Calíope lee, las claves SCYLLA_* de SUPPORTED, medido contra el servidor.
  • Los demás clientes de Cassandra, en cualquier lenguaje, no se abrieron.

Qué habla

  • La versión 4 del protocolo nativo, la que hablan Cassandra 4.1 y posteriores y ScyllaDB 2025.1 y posteriores, con cada respuesta casada con su petición por su stream.
  • El inicio de sesión con contraseña (SASL PLAIN contra PasswordAuthenticator), TLS con certificado de cliente opcional y túnel SSH.
  • Consultas con nivel de consistencia, paginación por paging_state, sentencias preparadas para los valores, lotes logged y unlogged, y traza cuando se pide.
  • Todos los tipos de CQL, escritos como los escribe cqlsh.
  • Un driver para los dos servidores: OPTIONS se contesta antes de iniciar sesión, y las claves SCYLLA_* de esa respuesta le dicen a Calíope con cuál de los dos habla.

Qué no habla

  • La versión 5 del protocolo y posteriores: la 4 es la que hablan los dos servidores en todas las versiones que Calíope admite.
  • La compresión, y REGISTER con sus eventos: un cliente de escritorio no usa ninguna de las dos.
  • El enrutado por token: el cliente habla con el punto de contacto del perfil, o con su alternativo.
  • El inicio de sesión con Kerberos y LDAP.

Elasticsearch y OpenSearch (REST)

De qué se escribió

  • La especificación de la API REST que publica Elastic, y la que publica el proyecto OpenSearch, las dos a una revisión fija: la de Elastic, del 20 de octubre de 2026, y la versión v0.2.0 de OpenSearch, del 25 de mayo de 2025.
  • Su documentación pública de la API y, donde ninguna dice bastante, los propios servidores, medidos contra Elasticsearch 9.5 y OpenSearch 3.9.
  • Kibana, OpenSearch Dashboards y los clientes oficiales, en cualquier lenguaje, no se abrieron.

Qué habla

  • La API REST por HTTP o HTTPS sobre URLSession de Apple, sin ninguna dependencia añadida, para Elasticsearch 8.18 y posteriores y OpenSearch 2.19 y posteriores.
  • El inicio de sesión con usuario y contraseña o, en Elasticsearch, con clave de API; y GET / al conectar, cuya respuesta le dice a Calíope con cuál de los dos habla.
  • TLS con tu propia autoridad de certificación y certificado de cliente opcional; desactivar la verificación sólo como elección explícita tuya, con un aviso visible; y túnel SSH.
  • Query DSL, y los lenguajes de tabla de cada producto: SQL en los dos, ES|QL en Elasticsearch y PPL en OpenSearch.
  • Restaurar una instantánea desde Instantáneas, con Restaurar: los índices que elijas, con otro nombre si quieres (rename_pattern), y el estado global del clúster sólo si lo pides.

Qué no habla

  • Lo que es de Kibana o de OpenSearch Dashboards: paneles, visualizaciones, Discover y alertas.
  • Reindexar, editar políticas de ciclo de vida, plantillas o pipelines, y la réplica entre clústeres: Calíope los enseña y deja cambiarlos al servidor.
  • El aprendizaje automático y la búsqueda vectorial por similitud: los campos vectoriales se enseñan, no se consultan.
  • Las funciones que piden una licencia de pago.