Socket Chat Solution?
Moderator: General Moderators
- AKA Panama Jack
- Forum Regular
- Posts: 878
- Joined: Mon Nov 14, 2005 4:21 pm
Until I can find time to better play around with sockets and making a front end, I'm going to use -Rojas- suggestion to have the backend only do the queries and push it out to the end users. perhaps by writing a small text file once a second and having the ajax script read that. it seems to me that one query per second (total, instead of once per user) and reading a small file (talking a few bytes here) would be way less server intensive.
Set Search Time - A google chrome extension. When you search only results from the past year (or set time period) are displayed. Helps tremendously when using new technologies to avoid outdated results.
You're wrong, PHP can operate as a daemon. In fact, http://fast-chat.net/ is implemented like imsure described but with IRC server substituted by a pure PHP daemon. I know this for sure because I consulted its developer regarding this architecture. And this aproach made it possible to cut down the server resources usage (cpu time) by a factor of ~10.AKA Panama Jack wrote:Unfortunately PHP CANNOT operate like a true socket server without a helper program such as SCREEN in linux.
Moreover, it might be possible to run PHP server via inetd... it could simplify the server (not a real daemon in this case) because inetd would handle LISTEN phase of connection... dunno. It needs to be researched.
Which is what I mentioned previously, regarding the #efnet bot. Its not running under screen. Its running as a daemon, non-stop.Weirdan wrote:You're wrong, PHP can operate as a daemon. In fact, http://fast-chat.net/ is implemented like imsure described but with IRC server substituted by a pure PHP daemon. I know this for sure because I consulted its developer regarding this architecture. And this aproach made it possible to cut down the server resources usage (cpu time) by a factor of ~10.AKA Panama Jack wrote:Unfortunately PHP CANNOT operate like a true socket server without a helper program such as SCREEN in linux.
I've answered the original poster, I've researched my posts, and I've provided the links to everything needed to do precisely what the OP wanted. I have no interest in further arguments with people on the topic.
Please elaborate, on the original posters solution. I must have missed it. Unless you're referring to the flash solution which isn't really a solution to the problem.Roja wrote:Which is what I mentioned previously, regarding the #efnet bot. Its not running under screen. Its running as a daemon, non-stop.Weirdan wrote:You're wrong, PHP can operate as a daemon. In fact, http://fast-chat.net/ is implemented like imsure described but with IRC server substituted by a pure PHP daemon. I know this for sure because I consulted its developer regarding this architecture. And this aproach made it possible to cut down the server resources usage (cpu time) by a factor of ~10.AKA Panama Jack wrote:Unfortunately PHP CANNOT operate like a true socket server without a helper program such as SCREEN in linux.
I've answered the original poster, I've researched my posts, and I've provided the links to everything needed to do precisely what the OP wanted. I have no interest in further arguments with people on the topic.
Okay, sorry to revive this topic, but I'm bouncing back and forth between so many projects.. its been a while since I've visited this one.
What do you guys think of my proposed solution?
- Have a backend script that will do *one* query per second to check the chat database for new entries.
- If there are some, write it to a small text file
- Have a hidden page in the chat that reads this text file (also polled once per second) and appends it to the chat contents (ajax-ish like script)
This would be saving a crapload of queries, but I understand file writing is slow. But a second interval should be way more than enough to write a file a few bytes in size.
Would this be less server intensive then 3 queries per second - per user?
In total there would be two actions per second.
- checking for new messages and writing them
- checking the text file for content and appending it to the chat area
This does bring up a problem of when there are no users in chat. This would be checking for new messages when there won't be any.
I'm interested in hearing you guys' opinions.
What do you guys think of my proposed solution?
- Have a backend script that will do *one* query per second to check the chat database for new entries.
- If there are some, write it to a small text file
- Have a hidden page in the chat that reads this text file (also polled once per second) and appends it to the chat contents (ajax-ish like script)
This would be saving a crapload of queries, but I understand file writing is slow. But a second interval should be way more than enough to write a file a few bytes in size.
Would this be less server intensive then 3 queries per second - per user?
In total there would be two actions per second.
- checking for new messages and writing them
- checking the text file for content and appending it to the chat area
This does bring up a problem of when there are no users in chat. This would be checking for new messages when there won't be any.
I'm interested in hearing you guys' opinions.
Set Search Time - A google chrome extension. When you search only results from the past year (or set time period) are displayed. Helps tremendously when using new technologies to avoid outdated results.
You're risking to lose some messages because client-side (ajax) polling is not synchronized to server-side polling (writing the file). There would be cases when a client did not receive previous chunk of messages because the server overwritten the file with a new chunk already.- Have a backend script that will do *one* query per second to check the chat database for new entries.
- If there are some, write it to a small text file
- Have a hidden page in the chat that reads this text file (also polled once per second) and appends it to the chat contents (ajax-ish like script)
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
I'm not sure that anything would be missed because it does not appear that what is being saved is a queue -- is sounds more like a snapshot of the current chat history. But it is always possible to miss something by reading before the next write in these systems -- but that gets fixed on the next read.Weirdan wrote:You're risking to lose some messages because client-side (ajax) polling is not synchronized to server-side polling (writing the file). There would be cases when a client did not receive previous chunk of messages because the server overwritten the file with a new chunk already.
I don't think I have seen anyone mention PHP's shared memory functions (shmop_*) but they might be of use here. You could maintain the chat queues in shared memory as they are not really that big.
But you need to install the shmop library in PHP, so it might not be available.
(#10850)
Is it possible to stream the text file?
Set Search Time - A google chrome extension. When you search only results from the past year (or set time period) are displayed. Helps tremendously when using new technologies to avoid outdated results.
Caching to a text file wont do you any good since it is such a simple select statement. If it were a complex select to get the chat history then caching might be a good idea, but it really shoudnt be anymore complicated than justscottayy wrote:Okay, sorry to revive this topic, but I'm bouncing back and forth between so many projects.. its been a while since I've visited this one.
What do you guys think of my proposed solution?
- Have a backend script that will do *one* query per second to check the chat database for new entries.
- If there are some, write it to a small text file
- Have a hidden page in the chat that reads this text file (also polled once per second) and appends it to the chat contents (ajax-ish like script)
This would be saving a crapload of queries, but I understand file writing is slow. But a second interval should be way more than enough to write a file a few bytes in size.
Would this be less server intensive then 3 queries per second - per user?
In total there would be two actions per second.
- checking for new messages and writing them
- checking the text file for content and appending it to the chat area
This does bring up a problem of when there are no users in chat. This would be checking for new messages when there won't be any.
I'm interested in hearing you guys' opinions.
Code: Select all
SELECT * FROM chat WHERE chatroom_id = 2 AND time_said > (last time the client polled the server)I think that the best way to create web IRC client is to AVOID using of php or another server side script, no matter compiled or not.
I've made php3/php4 irc webchat several years ago using technology similar to AJAX (frames communication, not xml, for compatibility with browsers like netscape 4.0... no longer supported). It is probably largest php webchat ever made by anyone anywhere. It had about 5200 users peak with largest channel with over 1700 users (~50%-70% of them were php webchat users and rest - mIRC, JAVA etc). I had constant need of more and more memory, servers, maintenance and care :/
I think now that adequate webchat is flash with direct connection to local IRC server without gateway. But I am not familiar with this technology and I don't know if it is possible with the use of flash XML sockets.
I've made php3/php4 irc webchat several years ago using technology similar to AJAX (frames communication, not xml, for compatibility with browsers like netscape 4.0... no longer supported). It is probably largest php webchat ever made by anyone anywhere. It had about 5200 users peak with largest channel with over 1700 users (~50%-70% of them were php webchat users and rest - mIRC, JAVA etc). I had constant need of more and more memory, servers, maintenance and care :/
I think now that adequate webchat is flash with direct connection to local IRC server without gateway. But I am not familiar with this technology and I don't know if it is possible with the use of flash XML sockets.