How do you store non-serializable, process-dependent objects between PHP requests?

We need to keep a collection of socket objects around associated with different client browser sessions, so when the client browser makes a subsequent request, we can use the existing connection / socket session to request them on behalf of. A socket is something that is not HTTP. Is there a way to store objects like this in PHP that will survive in all page requests?

+5
source share
4 answers

In php, the script dies after the page loads, so there is no way to do this. Hovewer, you can create a long-lived daemon that will open everything necessary for the process sockets and save it between page reloads. Of course, you need to isolate these sockets with a kind of passkey to make sure that different sessions will not have access to other user sockets. You also need to keep in mind that he will die at some point, so make sure you have the logic to restart all open sockets. But this can be achieved for sure.

Thanks.

+2
source

Is there a way to store objects like this in PHP that will survive in all page requests?

No.

To quote zombat answer to very similar question :

In PHP there is no concept of page instances. Every request to the web server is a new beginning. All classes are reloaded, therefore there is no concept of class sharing and there is no concept of a resource pool if it is not implemented externally. Thus, sharing sockets between web requests is not possible.

If the objects were serializable, you could use PHP serialize() and unserialize() in combination with MySQL memory tables to solve this problem. Other than that, I don’t think you can do much more.

+4
source

This is not a complete answer; but he comes up to the answer.

As already mentioned, advertising advertisements elsewhere, the standard classical model of using PHP via a web server (Apache, Nginx, etc.) does not allow you to do this, because each hacking of a page starts with a completely new set of variables.

Three thoughts:

  • You need a persistence layer. Obviously, here you are storing material in a database or using APC ( APCu in PHP7 +), Redis, or something similar.

However, your problem is that you specify "unserializable".

  1. My next suggestion would be, perhaps you could save the elements needed to create the object and reinitialize the object for each PHP request. It will not be as surprising as you would like, but it is the most useful solution without rewriting eveything. You may have already tried this.

  2. The next step is to do something completely out. One of the advantages of the NodeJS infrastructure is that the entire server cycle is maintained.

So, you can try one of the alternative methods for starting PHP, for example ReactPHP or PHP FastCGI . (There are others, but I can’t remember them from my head. I will edit this if I remember.)

This implies a completely different way of writing PHP - the same as programming NodeJS - this is the overlay of jQuery inside your browser. It will not work in Apache. Rather, it will run directly as an application on your Unix server. And you will need to handle things like garbage collection so you don't have memory leaks, and write nice hard event loops.

The positive side is that your thread is saved and processes each subsequent request, you can process requests exactly as you do after.

+2
source

Your comment mentions local sockets. And it looks like the PHP application is acting as a socket client. Thus, the only thing required in a PHP session is a common identifier, such as a user identifier, for sequentially named sockets.

So for example:

 <?php $userid = $_SESSION['userid']; $fp = stream_socket_client("unix:///tmp/socket-" . $userid, $errno, $errstr, 30); if ($fp) { fread... } 
-1
source

Source: https://habr.com/ru/post/1266667/


All Articles