I am working on a php application that is sending data through a socket. On my main page I establish the connexion with the client, and I would like to send data from another page of the web app.. but I don't know how to do that.
I am currently trying to use $_SESSION variables [close your eyes this is not pretty]
main page :
$socket = socket_create(AF_INET, SOCK_STREAM, 0);
$result = socket_bind($socket, $host, $port);
$result = socket_listen($socket, 3);
$_SESSION['mySocket'] = socket_accept($socket) ;
socket_read($_SESSION['mySocket'], 1024);
second page :
socket_write($_SESSION['mySocket'], "myText", 6) ;
But it does not work because $_SESSION['mySocket'] is not a ressource anymore on the second page (just 0)... If I use the write command on the main page it works fine, but not on another page. Do you have any idea why ? Is there a cleaner way to do that than using $_SESSION variables (surely there is) ?
EDIT : maybe my real question is : when does a socket connexion close (if I didn't ask for it) ?
Sockets are really only for CLI programming, and there you don't have a $_SESSION object available.
Additionally, it doesn't make sense that you will want to share the socket in the first place, because the socket is a means of IPC. If you pass the socket handle between scripts, then what use is the socket anyway?
If you are trying to communicate between one script and the other, you will want to have the first script listen on a socket (as you did), and then create an infinite loop where the script listens for requests.
In the second script, you connect to the same socket, but don't listen to it.
So I guess what you actually want to do, is to have a third file config.php:
And in both scripts use
You will want to expand this later to make the $host configurable independently, if you want to communicate between computers on a network.
All in all, this is quite advanced programming and you will need to read a lot more about sockets. If I haven't scared you off enough, you could read up on some example code as it is shown in the PHP manual.
Is it possible to connect to multiple html5 websocket connections ?
As i want to have one websocket connection for read and other websocket connection for write to socket.
I want to open at the same point of time with different connection ids.
For example:
$(document).ready(function () {
conn = {}, window.WebSocket = window.WebSocket || window.MozWebSocket;
connection1();
});
function connection1() {
// uses global 'conn' object
if (conn.readyState === undefined || conn.readyState > 1) {
conn1 = new WebSocket('ws://ip1:8101');
conn2 = new WebSocket('ws://ip1:8102');
//connection open
conn1.onopen = function () {
conn1.send("Connection1 Established Confirmation");
};
conn2.onopen = function () {
conn2.send("Connection2 Established Confirmation");
};
}
You do not need two sockets to write and read.
A websocket can both send data and receive data.
var socket = new WebSocket('ws://ip1:8101');
socket.onopen = function(){
socket.send("Hello server");
};
socket.onmessage = function(message){
// Handle the message
};
Yes, you definitely can.
In general, you probably just want to use the same WebSocket connection for both sending and receiving (the full-duplex, bidirectional nature of WebSocket is one of the things that distinguishes it from regular HTTP connections).
There are a few cases where you might want to have a multiple simultaneous WebSocket connections to the same server:
You are going to send very large messages in one direction or the other. Separating the connections allows you to keep the channel with large messages from affecting the latency of message on the other channel.
You have different security requirements for each channel. For example, you may allow any browser client to connect to the read only channel, but require authentication on the write channel. Also, running separate processes on the server for the read-only connection and the write connection lowers your vulnerability attack service (separation of concerns).
You have different scaling requirements for each channel. For example, you may have a consistent datastore behind the server that can have many readers but only a single writer at a time. In that case, it may make sense to serve read-only clients with a thread or process pool WebSocket server to allow those to scale easily.
The server is actually just a proxy to other WebSocket servers that are not directly visible to the client and they have different functions (e.g. receiving or sending data in your case).
Note that for the cases described above you don't necessarily need to use separate ports and could instead use different request paths in the connection and have logic in the server to get the connections to the right destination process/server.
There are other reasons to have separate simultaneous connections, but unless you have a specific reason I recommend using a single connection since other things being equal it is more efficient (for your browser, intermediaries and the server).
I am trying to implement a realtime chat application using PHP . Is it possible to do it without using a persistent data storage like database or file . Basically what I need is a mediator written in PHP who
accepts messages from client browsers
Broadcasts the message to other clients
Forgets the message
You should check out Web Sockets of html5. It uses two way connection so you will not need any database or file. Any chat message comes to the server will directly sent to the other users browser without any Ajax call. But you need also to setup web socket server.
Web sockets are used in many real time applications as well. I am shortly planing to write full tutorial on that. I will notify you.
Just tried something I had never done before in response to this question. Seemed to work but I only tested it once. Instead of using a Socket I had an idea of using a shared Session variable. Basically I forced the Session_id to be the same value regardless of the user therefore they are all sharing the same data. From a quick test it seems to work. Here is what I did:
session_id('12345');
session_start();
$session_id = session_id();
$_SESSION['test'] = $_SESSION['test'] + 1;
echo "session: {$session_id} test: {$_SESSION['test']} <br />";
So my thought process was that you could simply store the chat info in a Session variable and force everyone regardless of who they are to use a shared session. Then you can simply use ajax to continually reload the current Session variable, and use ajax to edit the session variable when adding a message. Also you would probably want to set the Session to never expire or have a really long maxlifetime.
As I said I just played around with this for a few minutes to see if it would work.
You will want to use Sockets. This article will cover exactly what you want to do: http://devzone.zend.com/209/writing-socket-servers-in-php/
When I tried to solve the same problem, I went with Nginx's Push Module. I chose to go this way since I had to support older browsers (that usually won't support WebSockets) and had no confidence in setting up an appropriate solution like Socket.io behind a TCP proxy.
The workflow went like this:
The clients connect through long-polling to my /subscriber location, which is open to all.
The /publisher location only accepts connections from my own server
When a client subscribes and talks, it basically just asks a PHP script to handle whatever data is sent.
This script can do validation, authorization, and such, and then forwards (via curl) the message in a JSON format to the /publisher.
Nginx's Push Module handles sending the message back to the subscribers and the client establishes a new long-polling connection.
If I had to do this all over again, then I would definitely go the Socket.io route, as it has proper fallbacks to Comet-style long-polling and has great docs for both Client and Server scripts.
Hope this helps.
If you have a business need for PHP, then adding another language to the mix just means you then have two problems.
It is perfectly possible to run a permanent, constantly-running daemonised PHP IRCd server: I know, because I've done it, to make an online game which ran for years.
The IRC server part I used is a modified version of WaveIRCd:
http://sourceforge.net/projects/waveircd/
I daemonised it using code I made available here:
http://www.thudgame.com/node/254
That code might be overkill: I wrote it to be as rugged as I could, so it tries to daemonise using PHP's pcntl_fork(), then falls back to calling itself recursively in the background, then falls back to perl, and so on: it also handles the security restrictions of PHP's safe mode in case someone turns that on, and the security restrictions imposed by being called through cron.
You could probably strip it down to just a few lines: the bits with the comments "Daemon Rule..." - follow those rules, and you'll daemonize your process just fine.
In order to handle any unexpected daemon deaths, etc, I then ran that daemoniser every minute through cron, where it checked to see if the daemon was already running, and if so either quietly died, or if the daemon was nonresponsive, killed it and took its place.
Because of the whole distributed nature of IRC, it was nicely rugged, and gave me a multiplayer browser game with no downtime for a good few years until bit-rot ate the site a few months back. I should try to rewrite the front end in Flash and get it back up again someday, when I have time...
(I then ran another daemonizer for a PHP bot to manage the game itself, then had my game connect to it as a java applet, and talk to the bot to play the game, but that's irrelevant here).
Since WaveIRCd is no longer maintained, it's probably worth having a hunt around to find if anyone else has forked the project and is supporting it.
[2012 edit: that said, if you want your front end to be HTML5/Javascript, or if you want to connect through the same port that HTTP connects through, then your options are more limited than when using Flash or Java. In that case, take the advice of others, and use "WebSockets" (poor support in most current browsers) or the "Socket.io" project (which uses WebSockets, but falls back to Flash, or various other methods, depending what the browser has available).
The above is for situations where your host allows you to run a service on another port. In particular, many have explicit rules in their ToS against running an IRCd.]
[2019 edit: WebSockets are now widely supported, you should be fine using them. As a relevant case study, Slack is written in PHP (per https://slack.engineering/taking-php-seriously-cf7a60065329), and for some time supported the IRC protocol, though I believe that that has since been retired. As its main protocol, it uses an API based on JSON over WebSockets (https://api.slack.com/rtm). This all shows that a PHP IRCd can deliver enterprise-level performance and quality, even where the IRC protocol is translated to/from another one, which you'd expect to give poorer performance.]
You need to use some kind of storage as a buffer. It IS plausable not to use file or db (which also uses a file). You can try using php's shared memory functions, but I don't know any working solution so you'll have to do it from scratch.
Is it possible to do it without using a persistent data storage like
database or file?
It is possible but you shouldn't use. Database or file based doesn't slows down chat. It will be giving additional security to your chat application. You can make web based chat using ajax and sockets without persistent data.
You should see following posts:
Is database based chat room bad idea?
Will polling from a SQL DB instead of a file for chat application increase performance?
Using memcached as a database buffer for chat messages
persistent data in php question
https://stackoverflow.com/questions/6569754/how-can-i-develop-social-network-chat-without-using-a-database-for-storing-the-c
File vs database for storage efficiency in chat app
PHP is not a good fit for your requirements (in a normal setup like apache-php, fastcgi etc.), because the PHP script gets executed from top to bottom for every request and cannot maintain any state between the requests without the use of external services or databases/files (Except e.g. http://php.net/manual/de/book.apc.php, but it is not intended for implementing a chat and will not scale to multiple servers.)
You should definitely look at Node.js and especially the Node.js module Socket.IO (A Websocket library). It's incredibly easy to use and rocks. Socket.IO can also scale to multiple chat servers with an optional redis backend, which means it's easier to scale.
Trying to use $_SESSION with a static session id as communication channel is not a solution by the way, because PHP saves the session data into files.
One solution to achieving this is by writing a PHP socket server.
<?php
// Set time limit to indefinite execution
set_time_limit (0);
// Set the ip and port we will listen on
$address = '192.168.0.100';
$port = 9000;
$max_clients = 10;
// Array that will hold client information
$clients = Array();
// Create a TCP Stream socket
$sock = socket_create(AF_INET, SOCK_STREAM, 0);
// Bind the socket to an address/port
socket_bind($sock, $address, $port) or die('Could not bind to address');
// Start listening for connections
socket_listen($sock);
// Loop continuously
while (true) {
// Setup clients listen socket for reading
$read[0] = $sock;
for ($i = 0; $i < $max_clients; $i++)
{
if ($client[$i]['sock'] != null)
$read[$i + 1] = $client[$i]['sock'] ;
}
// Set up a blocking call to socket_select()
$ready = socket_select($read,null,null,null);
/* if a new connection is being made add it to the client array */
if (in_array($sock, $read)) {
for ($i = 0; $i < $max_clients; $i++)
{
if ($client[$i]['sock'] == null) {
$client[$i]['sock'] = socket_accept($sock);
break;
}
elseif ($i == $max_clients - 1)
print ("too many clients")
}
if (--$ready <= 0)
continue;
} // end if in_array
// If a client is trying to write - handle it now
for ($i = 0; $i < $max_clients; $i++) // for each client
{
if (in_array($client[$i]['sock'] , $read))
{
$input = socket_read($client[$i]['sock'] , 1024);
if ($input == null) {
// Zero length string meaning disconnected
unset($client[$i]);
}
$n = trim($input);
if ($input == 'exit') {
// requested disconnect
socket_close($client[$i]['sock']);
} elseif ($input) {
// strip white spaces and write back to user
$output = ereg_replace("[ \t\n\r]","",$input).chr(0);
socket_write($client[$i]['sock'],$output);
}
} else {
// Close the socket
socket_close($client[$i]['sock']);
unset($client[$i]);
}
}
} // end while
// Close the master sockets
socket_close($sock);
?>
You would execute this by running it through command line and would always have to run for your PHP clients to connect to it. You could then write a PHP client that would connect to the socket.
<?php
$fp = fsockopen("www.example.com", 80, $errno, $errstr, 30);
if (!$fp) {
echo "$errstr ($errno)<br />\n";
} else {
$out = "GET / HTTP/1.1\r\n";
$out .= "Host: www.example.com\r\n";
$out .= "Connection: Close\r\n\r\n";
fwrite($fp, $out);
while (!feof($fp)) {
echo fgets($fp, 128);
}
fclose($fp);
}
?>
You would have to use some type of ajax to call with jQuery posting the message to this PHP client.
http://devzone.zend.com/209/writing-socket-servers-in-php/
http://php.net/manual/en/function.fsockopen.php
Better use a node.js server for this. WebSockets aren't cross-browser nowadays (except socket.io for node.js that works perfect)
in short answer, you can't.
the current HTTP/HTML implementation doesn't support the pushstate so the algorithm of your chat app should follow :
A: sent message
B,C,D: do while a new message has been sent get this message.
so the receivers always have to make a new request and check if a new message has been sent. (AJAX Call or something similar )
so always there are a delay between the sent event and the receive event.
which means the data must be saved in something global, like db or file system.
take a look for :
http://today.java.net/article/2010/03/31/html5-server-push-technologies-part-1
You didn't say it had to all be written it PHP :)
Install RabbitMQ, and then use this chat implementation built on top of websockets and RabbitMQ.
Your PHP is pretty much just 'chat room chrome'. It's possible most of your site would fit within the 5 meg limit of offline HTML5 content, and you have a very flexible (and likely more robust than if you did it yourself) chat system.
It even has 20 messages of chat history if you leave the room.
https://github.com/videlalvaro/rabbitmq-chat
If You need to use just PHP, then You can store chat messages in session variables, session could be like object, storing a lot of information.
If You can use jQuery then You could just append paragraph to a div after message has been sent, but then if site is refreshed, messages will be gone.
Or combining, store messages in session and update that with jQuery and ajax.
Try looking into socket libraries like ZeroMQ they allow for instant transport of the message, and are quicker than TCP, and is realtime. Their infrastructure allows for instant data send between points A and B, without the data being stored anywhere first (although you can still choose to).
Here's a tutorial for a chat client in ZeroMQ
i have a php server with an array of clients which are connected to the server..
is there a way for me to find out for how long each client is connected and if the client passed the timeout time to disconnect it ? does php save somewhere the time the socket were accepted ?
i'm trying to get rid of ghost clients..
i know that i can set the time the socket accepted myself and to loop throw it but my question if there is some kind of socket_get_connection_time() function of something similar ?
One way to handle this is using signals, if you are using a Unix-based platform (I don't believe this is available on Windows).
First, you need to make sure your PHP build includes the pcntl_* functions. See docs here:
http://php.net/manual/en/book.pcntl.php On many installations, it is not compiled in by default.
You would do something like this:
if( !function_exists( "pcntl_signal" ) ) {
die("pcntl_* functions not available");
}
pcntl_signal( 14, "cleanup", TRUE ); // 14 is the value for the SIGALARM unix signal
pcntl_alarm( XXXX ); // where XXXX is the number of second timeout for doing maintenance
function cleanup()
{
// do your checks for timed out sockets here.
// you will need some way to access the data, possibly a global variable pointing to
// to the list of socket connections.
}
I've got a chat program which pushes JSON data from Apache/PHP to Node.js, via a TCP socket:
// Node.js (Javascript)
phpListener = net.createServer(function(stream)
{
stream.setEncoding("utf8");
stream.on("data", function(txt)
{
var json = JSON.parse(txt);
// do stuff with json
}
}
phpListener.listen("8887", 'localhost');
// Apache (PHP)
$sock = stream_socket_client("tcp://localhost:8887");
$written = fwrite($sock, $json_string);
fclose($sock);
The problem is, if the JSON string is large enough (over around 8k), the output message gets split into multiple chunks, and the JSON parser fails. PHP returns the $written value as the correct length of the string, but the data event handler fires twice or more.
Should I be attaching the function to a different event, or is there a way to cache text across event fires, in a way that won't succumb to race conditions under heavy load? Or some other solution I haven't thought of?
Thanks!
You should try using a buffer, to cache the data, as Node.js tends to split data in order to improve performance.
http://nodejs.org/api.html#buffers-2
you can buffer all your request, and then call the function with the data stored at it.
TCP sockets don't handle buffering for you. How could it? It doesn't know what application layer protocol you are using and therefore has no idea what a "message" is. It is up to you to design and implement another protocol on top of it and handle any necessary buffering.
But, Node.js does have a built in application layer protocol on top of TCP that does automatically handle the buffering for you: the http module. If you use the http module instead of the tcp module for this you won't need to worry about packet fragmentation and buffering.