Tenemos la necesidad de mantener una colección de objetos de socket que estén asociados con diferentes sesiones del navegador del cliente, de modo que cuando el navegador del cliente realice una solicitud posterior, podamos usar la conexión/sesión de socket existente para realizar una solicitud en su nombre. El socket es para algo que no es HTTP. ¿Hay alguna forma de almacenar objetos como este en PHP que sobrevivan a través de las solicitudes de página?
¿Hay alguna forma de almacenar objetos como este en PHP que sobrevivan a través de las solicitudes de página?
No.
Para citar la respuesta de Zombat a una pregunta muy similar :
En PHP, no existe el concepto de instancias de página. Cada solicitud al servidor web es un nuevo comienzo. Todas las clases se vuelven a cargar, por lo que no existe el concepto de uso compartido de clases ni el concepto de agrupación de recursos, a menos que se implemente externamente. Por lo tanto, compartir sockets entre solicitudes web no es realmente posible.
Si los objetos fueran serializables, podría usar serialize() y unserialize() de PHP junto con las tablas de memoria de MySQL para resolver este problema. Aparte de eso, no creo que haya mucho más que puedas hacer.
Esta no es una respuesta completa; pero da un paso hacia una respuesta.
Como se ha señalado hasta la saciedad en otro lugar, el modelo estándar y clásico de usar PHP, a través de un servidor web (Apache, Nginx, etc.) no le permite hacer esto, porque cada visita a la página comienza con un conjunto completamente nuevo de variables.
Tres pensamientos:
Sin embargo, su problema es que especifica "no serializable".
Mi siguiente sugerencia sería, tal vez podría persistir los elementos necesarios para construir el objeto y reiniciar el objeto para cada solicitud de PHP. No tendrá un rendimiento tan sorprendente como le gustaría, pero es la solución más útil sin tener que volver a escribir todo. Quizás ya lo hayas probado.
El siguiente paso es hacer algo completamente fuera de lugar. Una de las ventajas que tiene la infraestructura de NodeJS es que todo el bucle del servidor persiste.
Por lo tanto, puede probar uno de los métodos alternativos para ejecutar PHP, como ReactPHP o PHP FastCGI . (Hay otros, pero no puedo recordarlos de la parte superior de mi cabeza. Editaré esto si lo recuerdo).
Esto implica una forma completamente diferente de escribir PHP, tan diferente como la programación de NodeJS es de rellenar con jQuery dentro de su navegador. No se ejecutaría dentro de Apache. Más bien, se ejecutaría directamente como una aplicación en su servidor Unix. Y tendrá que ocuparse de cosas como la recolección de elementos no utilizados para no tener fugas de memoria y escribir buenos bucles de eventos ajustados.
El lado positivo es que, debido a que su subproceso persiste y maneja cada solicitud posterior, puede manejar las solicitudes exactamente de la manera que está buscando.
En php, el script muere después de cargar la página, por lo que no hay forma de hacerlo. Sin embargo, puede crear un demonio de larga duración que abrirá todos los sockets de proceso requeridos y lo mantendrá abierto entre recargas de página. Por supuesto, deberá aislar estos sockets mediante algún tipo de clave de acceso para asegurarse de que las diferentes sesiones no tengan acceso a los sockets de otros usuarios. También debe tener en cuenta que morirá en algún momento, así que asegúrese de tener lógica para reiniciar todos los sockets que se abrieron. Pero se puede lograr con seguridad.
Gracias.