Ícono de la app Calíope

Los drivers que escribo

Seis clientes, cada uno escrito desde la especificación que publican sus autores.

Calíope habla con seis clases de servidor mediante clientes que escribí yo. Cada uno salió de la documentación que publican sus autores, no del código de otro cliente, 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.

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.

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 el descubrimiento por Sentinel: 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.

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.