Page 2 of 3
Posted: Mon Jun 19, 2006 8:02 pm
by Roja
bgzee wrote:You can't use sockets with javascript.
Really?
http://dev.dschini.org/socketjs/
Posted: Mon Jun 19, 2006 8:32 pm
by AKA Panama Jack
Actually that is not really java sockets.
He is using javascript to send data to an Flash/SWF program that is maintaining the socket connection. It's really a flash socket with a java interface. It's the flash program that is really sending and receiving the data over the socket connection.
About Flash Chat...
And we use Flash Chat at
http://www.aatraders.com for our chat room and we have it setup to use sockets instead of the normal HTTP. It is definitely faster and less intrusive on the server.
The way they are doing this is by starting a socket server using the Linux SCREEN program. This will maintain the socket connection even after PHP finishes execution. It will wakeup PHP and execute a PHP file if anything comes in over the socket connection. Then PHP will instantly mirror the data back to all clients connected to the socket. This way you do not have to have a PHP program constantly running using sleep commands or any other odd function.
It's an ingenious idea but it still has a flaw or two. The major flaw is if the socket hasn't been used for awhile the SCREEN process will shut down. I haven't figured out how to configure it to stay active constantly. As long as there is a client connected to the socket it will stay active. If there are no connected clients after awhile it will shut down on its own.
The quick fix is to set a schedule to run every 5-10 minutes to restart the socket if it has shut down.
Posted: Mon Jun 19, 2006 9:11 pm
by Roja
AKA Panama Jack wrote:Actually that is not really java sockets.

Wasn't meant to be.
I said use javascript to connect to a php socket solution, and he responded with "You can't use sockets with Javascript".
Now I post a solution that uses javascript to connect to a flash program (which in turn in connecting to a php socket solution), and its "not really".
The original poster wanted a way to have javascript chat, interfaced with sockets, to reduce overhead.
Multiple posts have offered multiple solutions that do *exactly* that.
Now, with that out of the way (grin)..
AKA Panama Jack wrote:The major flaw is if the socket hasn't been used for awhile the SCREEN process will shut down. I haven't figured out how to configure it to stay active constantly. As long as there is a client connected to the socket it will stay active. If there are no connected clients after awhile it will shut down on its own.
It shouldnt if you set the Idle configuration option to "0". I run screen on a number of machines, and on many occasions don't have any activity, yet I'm able to keep em running.
I think thats more a matter of screen than anything else.
Posted: Tue Jun 20, 2006 8:38 am
by santosj
That does give me an idea, but it seems to add complexity to a relative simple task. I mean, I suppose you'll have to learn PHP sockets and Sockets programming eventually, but to try someone as complex as this on the first run seems impossible.
Since I heard the key word, "Using Sockets is faster," I'm interested on how this Screen works and if it is at all possible on Shared hosting. I remember that Dreamhost doesn't allow such a command because of their policy of restricting persistent tasks. Is it at all possible to emulate screen using another method?
The main reason I went with HTTP instead of Sockets was that I felt that there would no benefit. I would have to send the data back and forth each time anyway.
Posted: Wed Jun 21, 2006 9:30 am
by bg
Yes, really. Show me a pure js example.
I pointed out earlier that if you wanted sockets you would have to use java or flash. Your post just reiterates that.
Posted: Wed Jun 21, 2006 9:46 am
by Roja
bgzee wrote:I pointed out earlier that if you wanted sockets you would have to use java or flash. Your post just reiterates that.
You don't have to use java or flash. You can alternatively use php on the backend, which was my point several posts ago.
The javascript is simply the presentation - the frontend. The backend can be a huge variety of technologies, even including php using sockets.
Posted: Wed Jun 21, 2006 10:32 am
by bg
Dude... we're talking JavaScript. Client side. No one is arguing the fact that php can implement sockets. But sockets on the back-end don't mean ish if the client side can't handle them. Bottom line is, javascript cannot do sockets natively. Sure, you could use java or flash on the client side, but that kinda defeats the purpose of an ajax application.
Posted: Wed Jun 21, 2006 10:57 am
by Roja
bgzee wrote:Dude... we're talking JavaScript. Client side. No one is arguing the fact that php can implement sockets. But sockets on the back-end don't mean ish if the client side can't handle them. Bottom line is, javascript cannot do sockets natively. Sure, you could use java or flash on the client side, but that kinda defeats the purpose of an ajax application.
I still think you are missing my point.
You can have ajax on the front end, receiving and sending data to php.
PHP in turn is making connections (not to ajax) via sockets.
No Java, no Flash, ajax still keeps the response quick for the client, and sockets keeps the overhead on the backend low.
Savvy?
Posted: Wed Jun 21, 2006 11:23 am
by Maugrim_The_Reaper
I don't see the problem - I find using a little flash to operate the socket from Javascript a very neat approach. I'm certainly savvy with the rest...
Posted: Wed Jun 21, 2006 11:25 am
by bg
Yes, apparently I am missing your point, because you are making no sense.
PHP in turn is making connections (not to ajax) via sockets.
Actually, PHP isn't doing anything. Apache (or whatever http server you're using) controls the socket on the back end and the web browser controls the socket on the client side. PHP is just doing the parsing. You can implement sockets in PHP, but you'd have to listen on a non-standard port, because like I said apache will be using (more than likely) port 80. Not only that, but contrary to what you said, you would need something on the client side that is capable of connecting to a socket, such as, and I feel like Ive said a million times before, java or flash.
PHP in turn is making connections (not to ajax) via sockets.
Yeah, that makes no sense. The client has to initiate connection to the server. Once again, not possible with javascript. Of course, we are technically using sockets all along, as that is how the web browser connects to the http server. However, we have no control of this socket, and on top of this, that partiular socket is limited to one protocol, HTTP.
The more you say, it becomes apparent the less you know. I think you should just let this one die and go do some research.
Posted: Wed Jun 21, 2006 11:33 am
by bg
Maugrim_The_Reaper wrote:I don't see the problem - I find using a little flash to operate the socket from Javascript a very neat approach. I'm certainly savvy with the rest...
The beauty of ajax is being free of third party plug-ins and running on technology completely native to the browser. We've always been able to make desktop-like applications using flash. It was never a huge deal for exactly that reason. AJAX comes along and allows you to create these type of applications using only html, css, and javascript. Once you add something else to the mix, it really loses its appeal, and IMO, is a hack.
Posted: Wed Jun 21, 2006 12:18 pm
by Roja
bgzee wrote:Yes, apparently I am missing your point, because you are making no sense.
As someone that actively uses a *socket based IRC bot* in *pure PHP*, I disagree.
As mentioned on a blog, PEARgirl (the Efnet pear channel bot) is written in pure php.
http://gluegadget.com/blog/index.php?/a ... bitch.html
Do make sure to follow the links in that blog to the packages that power it. Pure PHP, doing socket connections to IRC.
All you have to do from there is pipe the output to XML, and write an AJAX client that listens to it.
Here's a hint: Multiple people already have.
bgzee wrote:PHP in turn is making connections (not to ajax) via sockets.
Actually, PHP isn't doing anything.
Okay, you apparently aren't aware that PHP can in fact control sockets.
http://us3.php.net/manual/en/ref.sockets.php
bgzee wrote:You can implement sockets in PHP, but you'd have to listen on a non-standard port, because like I said apache will be using (more than likely) port 80.
Apparently you have a different goal.
My meaning was that the php script could (for the example given by the OP), open a socket to an IRC channel, and provide that to a client. It could do so in the form of XML responses, which the client received via AJAX.
PHP->JS, Sockets, chat. Thats what the OP wanted. No Java (JS!=Java), No Flash.
bgzee wrote:The more you say, it becomes apparent the less you know. I think you should just let this one die and go do some research.
I can't really see how much more I can do beyond point you to actual code that does what you say isn't possible.
Perhaps you should consider your tone, and attitude before "bringing this one back from the dead".
Posted: Wed Jun 21, 2006 12:45 pm
by bg
Let me point a few things out here:
I never said that PHP couldn't manage sockets. PHP connect to an IRC server using sockets? Easy.
Take the data from the IRC server and send it back to the client? Also easy, and never said this couldnt be done.
Really, at what point did you join this thread? The original posters main question-- Can you initiate a connection using sockets, to the server and have a live, always open connection to stream chat back to the browser? The answer is, using only JS, no. The browser will have to constantly poll the server for new input. I don't know if I can make it any clearer. It's like I keep saying, "The apple is red" and you keep replying with "no its not, the banana is yellow", as if they have anything to do with each other.
My point, as it has been the entire time, is that you cannot, not not not, do anything with sockets using purely javascript. Which essentially answers the question posed in this thread.
Posted: Wed Jun 21, 2006 1:57 pm
by AKA Panama Jack
Roja wrote:bgzee wrote:Yes, apparently I am missing your point, because you are making no sense.
As someone that actively uses a *socket based IRC bot* in *pure PHP*, I disagree.
As mentioned on a blog, PEARgirl (the Efnet pear channel bot) is written in pure php.
http://gluegadget.com/blog/index.php?/a ... bitch.html
Do make sure to follow the links in that blog to the packages that power it. Pure PHP, doing socket connections to IRC.
You have completely gone off topic. This is about writing a PHP Chat program using sockets. You have gone off and brought up completely unrelated things and taken the thread off topic. No one is disputing the use of sockets in PHP but this is about creating a PHP Chat program using sockets. It's not about creating anything to communicate to an IRC site with PHP sockets.
Sure that is a nice example of using sockets in PHP. Not very practical because once the PHP program finishes the socket is closed even if you do not use the disconnect.
What the original poster was talking about was using sockets in PHP to have persistent connections to various clients for a Chat Server. Unfortunately PHP CANNOT operate like a true socket server without a helper program such as SCREEN in linux. PHP can create a socket, communicate through it but it cannot keep it open between executions of PHP programs.
Please try to keep the thread on the topic the original poster was asking about.
Re: Socket Chat Solution?
Posted: Wed Jun 21, 2006 6:49 pm
by Nathaniel
scottayy wrote:But, there's a problem. The page that grabs the messages has 3 separate queries in it. So for any given user in chat, that's 3 queries per second. Ok, that's not bad. But say there's 20 people in chat... that's 60 queries per second. Still, not THAT bad, but if it gets more... you get the idea.
This thread seems to have gone way off topic, but if you're interested in reducing the number of queries per request, consider deleting the messages with a cron job or, if you don't have access to cron, having the script only delete messages from the db randomly (do like if rand(1,5) == 1; delete() for it to delete the messages, on average, once every five requests).