I am thinking of trying to write a chatroom (text) which will need a php program running on the server listening for incomming messages. (It wont be busy, it might have 10 users max at any one time.) Can I have a permanent program running in the background? How would I get the program running in the background, and how would I set it up so the program automatically booted again if the server went down for some reason? Could I do this for a c# program as well, if I chose to write my listener program in that?
php doesn't really work like that - where you can write an executable program that runs on the server. Most php chat programs are just scripts that run at certain intervals checking for input. But to answer your question in a more general way, you can't have an executable program running at the server level. Everything for your site has to run from within your site's home directory.
Thanks for the reply Hank, in which case I am confused. About a year ago I wrote a c# listener program on my localhost server. I started the listener program on my local host, then I ran my silverlight chat program. I typed some text into the SL program and sent it off, my listener program picked it up and sent it back to my SL program. At the moment I am writing a php listener program on the lines of this example: http://www.devshed.com/c/a/PHP/Socket-Programming-With-PHP/ Here is the php server side bit: <? // set some variables $host = "192.168.1.99"; $port = 1234; // don't timeout! set_time_limit(0); // create socket $socket = socket_create(AF_INET, SOCK_STREAM, 0) or die("Could not create socket\n"); // bind socket to port $result = socket_bind($socket, $host, $port) or die("Could not bind to socket\n"); // start listening for connections $result = socket_listen($socket, 3) or die("Could not set up socket listener\n"); // accept incoming connections // spawn another socket to handle communication $spawn = socket_accept($socket) or die("Could not accept incoming connection\n"); // read client input $input = socket_read($spawn, 1024) or die("Could not read input\n"); // clean up input string $input = trim($input); // reverse client input and send back $output = strrev($input) . "\n"; socket_write($spawn, $output, strlen ($output)) or die("Could not write output\n"); // close sockets socket_close($spawn); socket_close($socket); ?> This php script has to be continually running on my website (in the same way as my c# program had to be running on my localhost). I am probably getting all the lingo wrong (I am self-taught). How would I get the result I am looking for?
Ah - okay. Yeah, unfortunately, socket_create is not going to be something that you'll find many shared hosts allowing. It's not even enabled by default in php because it's a potential security issue. And as far as shared hosting is concerned it's a security issue and a resource issue. So that's not going to work here I'm afraid.
Thanks for the reply. No worries. So I guess at the moment I should put chat messages into a database and poll this every 5 or so seconds. What would be a good polling time so it does not put strain on the server? As an aside, have you heard of an upcoming tech called websockets? Obviously it is not available on most browsers at the moment, but when it is (for example on firefox at the moment you can over-ride the default and allow it) will that be possible? Here is an example: http://www.flynsarmy.com/2010/05/php-web-socket-chat-application/
That protocol hasn't even been standardized yet from what I understand, so I don't know how that's all going to shake out. I think we're some time away from that being a workable alternative.
Is my suggested 5 second polling of the database ok? Will that put too much strain on a server? Could I get away with a shorter polling time? I am hoping for about 10 users at a time, but I guess it is probably best to assume maybe 100 so I am overcompensating.
Maybe. But bear in mind it is still a shared server, so there's a sort of diminishing return on doing a query, say, every second, because at some times you're going to be sending a query before the previous one returns a result. I'm not saying it consistently takes more than a second to get a result, just that server load fluctuates, and sometimes the response could lag a bit, that's unavoidable. You should try it at the longest interval that's workable for you and see how it goes. You can tighten it up from there.
