1. Deribit Soporte
  2. Soporte
  3. Información técnica

Administración de conexiones: prácticas recomendadas

  • Actualización

Los usuarios pueden conectarse a la plataforma Deribit mediante un con ámbito de conexión o con ámbito de sesión token de autenticación. Cada enfoque tiene propiedades, tiempos de vida y limitaciones diferentes. Comprender cómo funcionan estos ámbitos ayuda a garantizar una conectividad fiable, un uso óptimo de las funciones de WebSocket y el cumplimiento de los límites de la plataforma, como el número de conexiones o sesiones simultáneas por clave de

Límites

  • Número máximo de subcuentas: 20

  • Cantidad máxima de claves de API por (sub) cuenta: 8

  • Cantidad máxima de conexiones por IP: 32

  • Número máximo de sesiones por clave de API: 16

Conexión

A conexión es un enlace único y continuo entre un cliente y un servidor a través de una red. Los usuarios pueden autenticarse con connection alcance, y estas conexiones de autenticación son no se tienen en cuenta para el límite. Cuando ninguno connection ni session el alcance se especifica en la solicitud, el servidor utilizará de forma predeterminada el connection alcance.

Límite de conexión

Deribit impone un límite de 32 conexiones simultáneas por dirección IP, independientemente de si el usuario está autenticado o no. Este límite se aplica a todas las conexiones actualmente abiertas, incluidas

  • Solicitudes HTTP (GET/POST) — cada solicitud abre una nueva conexión durante su duración

  • Conexiones WebSocket — la conexión permanece abierta mientras dure la conexión

Atención

El límite de 32 conexiones cubre ambos con alcance de sesión y ámbito de conexión conexiones. Por ejemplo, puede abrir 16 de cada tipo, o 1 conexión por sesión y 31 conexiones estándar. Cualquier intento de establecer un 33a conexión desde la misma IP se rechazará con un HTTP 429 (demasiadas solicitudes) respuesta.

Nota

El Deribit La página web utiliza 2 conexiones activas por sesión de usuario. Tenga esto en cuenta al diseñar integraciones de alta frecuencia o con varias pestañas para evitar superar involuntariamente

Alcance de la conexión

  • Los tokens solo son válidos durante la conexión activa. Una vez finalizada la conexión, los tokens dejan de ser válidos y se requiere un nuevo proceso de autenticación para establecer una nueva conexión.

  • Los tokens de acceso y actualización están estrictamente vinculados a la conexión específica en la que se otorgaron.

Sesión

Una sesión se extiende más allá de una sola conexión y representa un período de interacción entre un usuario y un servidor, posiblemente a través de varias conexiones. Los usuarios pueden autenticarse con el session:name posibilidad de vincular su conexión con una sesión con nombre.

Límite de sesión

Deribit aplica una límite de 16 sesiones activas por clave de API o inicio de sesión con nombre de usuario/contraseña.

Se crea una nueva sesión cuando:

  • Genera un nuevo token de autenticación y especifica un nombre de sesión a través del session:name ámbito, o

  • Llama al punto final público/de autenticación sin proporcionar un nombre de sesión.

Si se crea una nueva sesión más allá del límite de 16 sesiones, el la sesión activa más antigua se elimina automáticamente.

Alcance de la sesión

  • Los tokens emitidos se pueden usar en diferentes conexiones, lo que resulta beneficioso cuando la conexión de un usuario puede interrumpirse de forma intermitente.

  • Los tokens están vinculados a la sesión, no a ninguna conexión específica, lo que permite a los usuarios volver a conectarse con los mismos tokens hasta que caduque la sesión.

  • Este ámbito es ideal para entornos en los que los usuarios cambian entre dispositivos o conexiones de red, ya que no requiere una autenticación repetida.

  • Cuando se usa WebSocket también permite omitir el suministro access_token con cada solicitud posterior.

  • La reautenticación con un token de actualización en el ámbito de la sesión no agrega nuevas sesiones, sino que actualiza la existente.

Mejores prácticas para una administración de conexiones eficiente y confiable

  1. Prefiera las suscripciones a las encuestas REST

    • Usa WebSocket suscripciones (por ejemplo, suscribirse) siempre que sea posible, en lugar de sondear continuamente los datos a través de puntos finales REST.

    • Las suscripciones son más eficientes, reducen la latencia y ayudan a mantenerse dentro límites de velocidad.

  2. No utilice WebSocket como REST

    • Evita patrones como:

      Abrir sesión → Leer una vez → Cerrar → Repetir.

      Esto es ineficiente y puede llevar a pérdida de conexiones y estrangulamiento.

    • En lugar de ello, mantener las sesiones abiertas y usar suscripciones en tiempo real o solicitudes por lotes.

  3. Utilice solicitudes autenticadas siempre que sea posible

    • Incluso para datos públicos, prefiera conexiones WebSocket autenticadas.

    • Los usuarios autenticados se benefician de límites de velocidad más altos y son es menos probable que tengan una velocidad de IP limitada o desconectado.

    • Si se detecta algún abuso o uso indebido, nosotros contactamos de manera proactiva a los clientes autenticados antes de tomar medidas restrictivas.

  4. Evite sobrecargar su conexión

    • Suscribirse a demasiados canales a la vez puede provocar un connection_too_slow error. Esto ocurre cuando el cliente no puede leer todos los eventos entrantes con la suficiente rapidez, provocando un atraso de mensajes pendientes.

    • Para evitar la desconexión:

      • Suscríbete solo a los canales necesarios.

      • Asegúrese de que su cliente lea y procese los mensajes de manera eficiente y continua.

Duración de la conexión HTTP

Cada conexión HTTP establecida tiene un temporizador de caducidad de 15 minutos. Los usuarios que deseen mantener una conexión HTTP más allá de este período deben utilizar la autorización de firma para continuar accediendo sin afectar a los límites de la sesión

Cancelar al desconectar

La función Cancelar al desconectar (COD) de API admite dos tipos de ajustes de alcance: conexión y cuenta. Tenga en cuenta que la cancelación al desconectarse no está permitida a través de HTTP.

  • Alcance de la conexión: Cuando el COD se establece con el alcance como conexión, se aplica solo a la conexión específica a través de la cual se establece. Esta configuración no afecta a ninguna otra conexión existente o futura. Cada conexión debe habilitar el COD de forma individual si es necesario.

  • Alcance de la cuenta: Al establecer el alcance del COD en la cuenta, la función se extiende a la conexión inicial en la que está configurada y se aplica automáticamente a todas las conexiones posteriores realizadas con la misma cuenta. Esto garantiza que el COD esté habilitado de forma predeterminada para las conexiones nuevas sin necesidad de configurarlo individualmente para cada una de ellas.

Sugerencia

Para mejorar la confiabilidad de la activación del COD, se recomienda habilitar los latidos del corazón en tus conexiones de WebSocket. Los Heartbeats permiten a la plataforma detectar conexiones obsoletas o caídas con mayor rapidez y activar el COD antes

Implementación de FIX

Al iniciar una sesión con el Logon (A) mensaje, los usuarios tienen la opción de habilitar o deshabilitar la cancelación al desconectarse para esa sesión mediante la etiqueta 9001. Más adelante, al cerrar sesión, pueden anular esta configuración Tag 9003.

Tipos de mensajes

  • Logon (A): Inicia la sesión. Debe ser el primer mensaje enviado por el cliente

  • LogOut (5): Lo usa cualquiera de las partes para terminar la sesión. El remitente debe esperar a que se oiga un eco antes de cerrar el conector.

Etiquetas

  • Tag 9001 - CancelOnDisconnect: indicador booleano que controla el COD a nivel de sesión. El valor predeterminado es false (N). Si no se especifica, se usa la configuración predeterminada de la cuenta.

  • Tag 9003 - DontCancelOnDisconnect: Si se establece en Y, desactiva el COD para la conexión a pesar de la configuración anterior al inicio de sesión o a nivel de cuenta. El valor predeterminado es false (N).