Topic awaiting preservation: PHP OO Classes and Instantiation

Just a quick question or three. I'm currently writing a PHP script that will connect to a remote server and communicate via a socket. Putting and getting commands and such forth. I'm taking my first stab at using classes in PHP to try and create a non-blocking command buffer so that this script can process multiple commands at once, even if the output resulting from one command will take a while to be recieved at the other end. So, each line that gets read from the command buffer (up to a maximum of, say, 5 or 7 commands processing at one time, because infinite limits on things will just cause problems) will instantiate its own version of the command processor, and then once that command is done, it removes itself and waits for the next.

So, we come to the questions:

1. If I instantiate a class into a variable, how do I then destroy that instantiation and free it so it can be done over?

2. Would this be better done by, say, having the main program monitor the socket buffer, pull out commands, and passing them onto a dedicated class for that command?

What are your ideas on this? Ever done a bot like this before, to process commands and return results through a socket to (in this case) an IRC Server? I'd love to hear suggestions.


Justice 4 Pat Richard

Answer to
1. If I instantiate a class into a variable, how do I then destroy that instantiation and free it so it can be done over?

-->That's pretty easy, all you do is (i.e. the name of your instantiation is $inst) 'unset($inst);' if you're working from the application. If you need it to self-destruct, all you do is 'settype($this, "null");' inside of the instance.

quote:

---

Skaarjj said:

2. Would this be better done by, say, having the main program monitor the socket buffer, pull out commands, and passing them onto a dedicated class for that command?

---

I would say no. The less work you can have the main program do before it passes control to the child program, the better. If the main program is taking time to parse the commands before passing the process off to a child program, that is time when another request can come in and be blocked or lost. If the main program receives the request at the socket and passes the socket and port combination to a child, it can start preparing another child to process the next request while the first child is processing the first request.

What you are writing is the server part of a client-server process. I assume you knew that already.

.



-- not necessarily stoned... just beautiful.

Actually what it technically is is the response-server part of a server-to-multiclient relationship. This will eventually form an IRC bot, so it's not a full IRCD server, not by a long-shot. From the IRCD's point of view it's another client. From the client's point of view it's a network service. But, good to know my original idea is the better. Thanks!


Justice 4 Pat Richard

Oh... I see what you meant, though, hyperbole, and you've got it a little backwards. This script doesn't accept incoming sockets, it generates an outgoing socket to an existing server.


Justice 4 Pat Richard