Dinaup 2027.1: tu servidor tiene dirección propia y play corre a su lado
Dinaup 2027.1 da a tu servidor una dirección propia, <clave>.dinaup.io, y ejecuta play en la misma máquina. Qué cambia, qué no cambia y qué tienes que hacer.
Ángel AlbaladejoTu empresa tiene su propio servidor en Dinaup. Es un proceso solo para ti, con tu base de datos. Hasta ahora todas las peticiones entraban por una dirección común, api.dinaup.com. Allí un programa buscaba tu servidor en un directorio. Después reenviaba la petición.
Con Dinaup 2027.1 tu servidor tiene dirección propia: <clave>.dinaup.io. Y play corre en la misma máquina que tu servidor.
Este artículo explica tres cosas. Por dónde viaja cada petición. Qué hace el servidor cuando recibe demasiadas peticiones. Y cómo leer el número de versión. Para ver qué cambia en las ventanas, lee Novedades de Dinaup 2027. Si solo usas play, lee los dos primeros apartados. Si integras por la API o con el SDK .NET, lee todos.
Tu servidor tiene dirección propia: <clave>.dinaup.io
Tu clave de conexión ya forma parte de tu endpoint: https://api.dinaup.com/v2/<clave>. Ahora esa clave es también una dirección de Internet. La dirección apunta a la máquina donde corre tu servidor. En este artículo la llamamos tu máquina.
Dinaup crea un registro DNS por empresa. Lo revisa cada cinco minutos. Si tu servidor cambia de máquina, Dinaup actualiza el registro. No tienes que configurar nada. Cloudflare protege la dirección nueva, igual que api.dinaup.com. En tu máquina, Dinaup entrega la petición a tu servidor.
La petición es la misma en las dos direcciones. Misma ruta, misma clave API, misma firma y misma respuesta. Solo cambia el dominio.
api.dinaup.com/v2/<clave> | <clave>.dinaup.io/v2/<clave> | |
|---|---|---|
| Quién localiza tu servidor | Un programa en Cloudflare, con una consulta a un directorio por petición | El DNS. La dirección ya es el destino. |
| Pasos hasta tu servidor | Cloudflare, el programa, el directorio, tu máquina | Cloudflare, tu máquina |
| Sigue funcionando | Sí | Sí |
Para una integración nueva, usa tu dirección propia. Para las integraciones que ya funcionan, no cambies nada. api.dinaup.com sigue funcionando.
Para comprobar que tu dirección responde, ejecuta este comando:
curl https://<clave>.dinaup.io/v2/<clave>/pingSi tu dirección no responde
Desplegamos 2027.1 máquina a máquina. Tu máquina todavía no tiene la versión. O tu licencia no está operativa. Sigue usando api.dinaup.com. Es la misma API.
Play corre en la misma máquina que tu servidor
Cada acción en play envía una petición a tu servidor. Hasta ahora play corría en un solo sitio, play.dinaup.com. Cada petición viajaba desde allí hasta tu servidor por api.dinaup.com.
Con 2027.1 cada máquina ejecuta su propio play. Las empresas de tu máquina entran por play-<clave>.dinaup.com. En este artículo lo llamamos tu play.
Tu play envía las peticiones por la red interna de tu máquina. La petición no sale a Internet. No pasa por Cloudflare. No necesita cifrado, porque no sale de la máquina.
Tu play comprueba qué caminos tiene disponibles y usa el más corto:
- La red interna de tu máquina. Es el caso normal.
<clave>.dinaup.io, a través de Cloudflare. Sirve cuando play corre en otra máquina.api.dinaup.com, el camino de siempre. Play no lo comprueba. Si los dos primeros fallan, usa este. Por eso ninguna empresa se queda sin API.
La comprobación es una llamada a /ping. /ping solo responde cuando el servidor está listo. Play guarda el resultado durante cinco minutos.
El viaje de cada petición es más corto. El tiempo dentro de tu base de datos no cambia.
play.dinaup.com te envía a tu play
Entras en play.dinaup.com como siempre. play.dinaup.com comprueba tu sesión y te envía a tu play. Tu navegador no nota el cambio: la dirección sigue siendo play.dinaup.com.
- Con la sesión abierta, entras en tu play.
- Sin sesión,
play.dinaup.comte lleva al login. - Si el servicio de sesiones no responde, entras igual. Play comprueba la sesión por su cuenta, como siempre.
- Si tu play todavía no existe, entras en el play central.
Una petición abandonada ya no se ejecuta
El servidor cambia de motor HTTP. Deja HttpListener y usa Kestrel, el motor de ASP.NET Core. El motivo no es la velocidad. Una petición gasta su tiempo en la base de datos. Leer cabeceras no cuesta tiempo. El motivo son tres cosas que el motor anterior no ofrecía.
El servidor detecta cuándo tu programa deja de esperar. Entonces retira la petición de la cola. Antes, el servidor la ejecutaba entera cuando llegaba su turno, y escribía. En una importación, eso creaba una fila duplicada: tu programa daba la petición por fallida y la repetía.
El servidor limita lo que antes no limitaba. El tamaño de una petición que no declara el suyo. El tiempo para enviar las cabeceras. Las conexiones inactivas. Un cliente lento ya no ocupa una conexión sin límite.
El servidor tiene menos formas de fallar. Ya no hay un hilo de escucha que pueda detenerse. Antes, ese fallo dejaba el proceso vivo y sin atender. Además responde en /vivo mientras acepta conexiones. /ping solo responde cuando está listo para trabajar.
Las rutas y las respuestas no cambian. El servidor procesa las peticiones igual que antes, sobre otro motor.
El servidor necesita tu tiempo de espera. Con él retira a tiempo una petición abandonada. El SDK 10.15.0.46 lo envía en cada petición, en la cabecera X-Dinaup-Timeout-Ms. El servidor solo la usa para acortar su reloj, nunca para alargarlo. Si llamas a la API por tu cuenta, envía esa cabecera.
Cola, tope y freno: qué pasa con demasiadas peticiones
Cada clave API atiende tantas peticiones a la vez como vCPUs tiene. El resto espera en cola. La cola admite 100 peticiones. Con más de 100, el servidor responde 503 con la cabecera Retry-After. Por encima de las claves hay un tope por empresa: los vCores contratados. Así diez claves de 20 vCPUs no suman 200 peticiones.
El freno de ritmo existe desde la versión 65.7624. Responde 429 cuando una clave supera su tarifa por vCore. La novedad de 2027.1 es que el SDK respeta el freno:
- Lee
Retry-After, espera ese tiempo y reintenta una vez. El reintento cabe en el tiempo que tú pediste. Si pediste nueve segundos, esperas nueve como máximo. - Un
429nunca ejecutó la petición. El SDK siempre la reintenta. - El SDK reintenta un
503solo en lecturas. Una escritura puede haberse ejecutado sin respuesta. Repetirla crearía una fila duplicada.
Si llamas a la API desde otro lenguaje
Aplica la misma regla. Lee Retry-After y espera ese tiempo. No reintentes una escritura después de un 503. El servidor nunca envía un Retry-After de cero.
Cómo leer la versión: 2027.1.7629
| Parte | Qué es |
|---|---|
2027 | El año de la línea. |
1 | La línea dentro del año. |
7629 | La revisión. Sube con cada publicación y nunca vuelve a cero. |
Play usa el mismo esquema: 2027.1.121. Su número sube con cada publicación de play.
El esquema permite que dos líneas convivan. Una empresa sigue en 2027.1 y otra pasa a 2027.2. Cada máquina ejecuta el play y el servidor de su línea. En play, la versión aparece en el pie y en /Version. En la API, en la función version.
Preguntas frecuentes
Siguiente paso
- Para conectar el SDK .NET y colocar el endpoint: Cliente Dinaup.
- Para ver tu endpoint base y probarlo con
curl: Desarrollo → Inicio en play. - Para crear o revisar claves API: Claves API.
- Para el detalle de cada revisión: Novedades de septiembre de 2026.
