RE: Re: [PHP] Full-Duplex communication
Hi Miguel, I can go in for a php based listener, yes, but this system is already in a production environment and there will be major changes required to get it done. If I get a chance to redevelop this, that is probably what I'll go in for. Tx, Vinod. -Original Message- From: Miguel Cruz [mailto:[EMAIL PROTECTED]] Sent: Friday, May 24, 2002 10:18 PM To: Vinod Panicker Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Re: [PHP] Full-Duplex communication So still there is nothing in your requirements that doesn't suggest you'll do fine with a PHP-based listener. Of course you have the memory overhead of the PHP interpreter's RAM infrastructure multiplied by the number of simultaneous connections, but that would be the same with Apache (at least on Unix). miguel On 24 May 2002, Vinod Panicker wrote: Let me explain my project more in detail. This system is an Instant messaging system, with the backed running on apache / php / mysql. The front end client is a COM component that communicates with the backend, and interfaces with an MFC app. Now since Instant messaging requires that the server should be able to send asynchronous messages to the client (Presence, IM's, notifications, etc), and HTTP does not allow asynchronous communication, the only solution is to have the client poll the server for messages. Now i know that apache / php is not a good solution for an instant messaging server, but we needed it to be ready in a months time, and php is so amazing that we could get it up and running so fast. But it meant that we have to live with latency between messages because of the polling. So i was thinking if there was some way in which i could avoid the polling and send data asynchronously to the client (Pls refer to my previous posts). Thats why i was looking at a way in which i could get hold of the socket to the client, so i could use it to send data directly. Tx, Vinod. On Fri, 24 May 2002 Miguel Cruz wrote : Not to be argumentative, but what you're trying to do is just so amazingly much more complicated than any of my suggestions. Maybe I haven't communicated it well, it maybe there's some requirement to your project that I don't understand. Why not just write a listener in PHP and redirect to it? It's basically no work. Handcrafting packets for this purpose is like building a car out of paper clips and cat hair because the car that's freely available to you is red - and you don't like the color red because your old girlfriend used to wear it a lot. miguel On 23 May 2002, Vinod Panicker wrote: What you said did make sense, and complements my knowledge of sockets. But what i'm not sure of is this - if i construct my own packet and send it across, presuming that i do have the ip address and port number of the client on which it is reading, will the client accept it as a legitimate packet? I suspect that since the packets would be having some kind of session identifier / sequence number. Getting the ip address and port number is no problem. I already have that getting stored on the server. But from what i know of sockets, i'm sceptical if the client will accept the packet. Guess the only way to go ahead is to try this out. Would someone pls pls pls write a PHP interface to libnet?? Tx, Vinod. On Thu, 23 May 2002 Evan Nemerson wrote : You're right- this is getting interesting ;) http://www.packetfactory.net/libnet/manual/4.html#s4.1.5 Unless I'm mistaken, you don't need to actually hijack the socket- you merely need to write to the network. Check out section 3.1 of RFC 793. There is source and destination port- that is how they are routed. Okay anyone PLEASE correct me if i'm wrong... My understanding is a socket is an interface to the kernel. So basically, you talk to a socket, which the kernel associates with source and destination ports, and destination IP address. Thats why you can just write to a socket instead of explicitly stating all the information. The kernel then sends out then creates the packet and send it to the destination IP. libnet would allow you to bypass the socket phase, and manually create a socket. Think of a socket as a GUI for the network, and libnet is like a console ;) Hope that helps, and once again anyone PLEASE correct any inaccuracies, since I want to know. On Tuesday 21 May 2002 23:53 pm, Vinod Panicker wrote: Thanks for the reply Miguel, but here i'm not trying to implement my own multi-threaded server - exactly the reason why i'm using Apache / PHP. I could have made a listening server which is based on a multi-threaded or multi-forked model, but the time and complexities involved would be huge. Thats why I chose Apache
Re: Re: [PHP] Full-Duplex communication
So still there is nothing in your requirements that doesn't suggest you'll do fine with a PHP-based listener. Of course you have the memory overhead of the PHP interpreter's RAM infrastructure multiplied by the number of simultaneous connections, but that would be the same with Apache (at least on Unix). miguel On 24 May 2002, Vinod Panicker wrote: Let me explain my project more in detail. This system is an Instant messaging system, with the backed running on apache / php / mysql. The front end client is a COM component that communicates with the backend, and interfaces with an MFC app. Now since Instant messaging requires that the server should be able to send asynchronous messages to the client (Presence, IM's, notifications, etc), and HTTP does not allow asynchronous communication, the only solution is to have the client poll the server for messages. Now i know that apache / php is not a good solution for an instant messaging server, but we needed it to be ready in a months time, and php is so amazing that we could get it up and running so fast. But it meant that we have to live with latency between messages because of the polling. So i was thinking if there was some way in which i could avoid the polling and send data asynchronously to the client (Pls refer to my previous posts). Thats why i was looking at a way in which i could get hold of the socket to the client, so i could use it to send data directly. Tx, Vinod. On Fri, 24 May 2002 Miguel Cruz wrote : Not to be argumentative, but what you're trying to do is just so amazingly much more complicated than any of my suggestions. Maybe I haven't communicated it well, it maybe there's some requirement to your project that I don't understand. Why not just write a listener in PHP and redirect to it? It's basically no work. Handcrafting packets for this purpose is like building a car out of paper clips and cat hair because the car that's freely available to you is red - and you don't like the color red because your old girlfriend used to wear it a lot. miguel On 23 May 2002, Vinod Panicker wrote: What you said did make sense, and complements my knowledge of sockets. But what i'm not sure of is this - if i construct my own packet and send it across, presuming that i do have the ip address and port number of the client on which it is reading, will the client accept it as a legitimate packet? I suspect that since the packets would be having some kind of session identifier / sequence number. Getting the ip address and port number is no problem. I already have that getting stored on the server. But from what i know of sockets, i'm sceptical if the client will accept the packet. Guess the only way to go ahead is to try this out. Would someone pls pls pls write a PHP interface to libnet?? Tx, Vinod. On Thu, 23 May 2002 Evan Nemerson wrote : You're right- this is getting interesting ;) http://www.packetfactory.net/libnet/manual/4.html#s4.1.5 Unless I'm mistaken, you don't need to actually hijack the socket- you merely need to write to the network. Check out section 3.1 of RFC 793. There is source and destination port- that is how they are routed. Okay anyone PLEASE correct me if i'm wrong... My understanding is a socket is an interface to the kernel. So basically, you talk to a socket, which the kernel associates with source and destination ports, and destination IP address. Thats why you can just write to a socket instead of explicitly stating all the information. The kernel then sends out then creates the packet and send it to the destination IP. libnet would allow you to bypass the socket phase, and manually create a socket. Think of a socket as a GUI for the network, and libnet is like a console ;) Hope that helps, and once again anyone PLEASE correct any inaccuracies, since I want to know. On Tuesday 21 May 2002 23:53 pm, Vinod Panicker wrote: Thanks for the reply Miguel, but here i'm not trying to implement my own multi-threaded server - exactly the reason why i'm using Apache / PHP. I could have made a listening server which is based on a multi-threaded or multi-forked model, but the time and complexities involved would be huge. Thats why I chose Apache / PHP. Now if what i'm asking for can be done, developers can easily leverage existing efficient server technologies (Apache) to build their own App servers. I know that there is no existing function in PHP that would allow it to retrieve the socket from Apache ;), all i'm asking for is a hack that would allow me to do it. I thought that i'd just as well post it on the mailing
Re: [PHP] Full-Duplex communication
Hi Evan, What you said did make sense, and complements my knowledge of sockets. But what i'm not sure of is this - if i construct my own packet and send it across, presuming that i do have the ip address and port number of the client on which it is reading, will the client accept it as a legitimate packet? I suspect that since the packets would be having some kind of session identifier / sequence number. Getting the ip address and port number is no problem. I already have that getting stored on the server. But from what i know of sockets, i'm sceptical if the client will accept the packet. Guess the only way to go ahead is to try this out. Would someone pls pls pls write a PHP interface to libnet?? Tx, Vinod. On Thu, 23 May 2002 Evan Nemerson wrote : You're right- this is getting interesting ;) http://www.packetfactory.net/libnet/manual/4.html#s4.1.5 Unless I'm mistaken, you don't need to actually hijack the socket- you merely need to write to the network. Check out section 3.1 of RFC 793. There is source and destination port- that is how they are routed. Okay anyone PLEASE correct me if i'm wrong... My understanding is a socket is an interface to the kernel. So basically, you talk to a socket, which the kernel associates with source and destination ports, and destination IP address. Thats why you can just write to a socket instead of explicitly stating all the information. The kernel then sends out then creates the packet and send it to the destination IP. libnet would allow you to bypass the socket phase, and manually create a socket. Think of a socket as a GUI for the network, and libnet is like a console ;) Hope that helps, and once again anyone PLEASE correct any inaccuracies, since I want to know. On Tuesday 21 May 2002 23:53 pm, Vinod Panicker wrote: Thanks for the reply Miguel, but here i'm not trying to implement my own multi-threaded server - exactly the reason why i'm using Apache / PHP. I could have made a listening server which is based on a multi-threaded or multi-forked model, but the time and complexities involved would be huge. Thats why I chose Apache / PHP. Now if what i'm asking for can be done, developers can easily leverage existing efficient server technologies (Apache) to build their own App servers. I know that there is no existing function in PHP that would allow it to retrieve the socket from Apache ;), all i'm asking for is a hack that would allow me to do it. I thought that i'd just as well post it on the mailing list before diving into the source code and trying to figure out for myself. No point trying to re-invent the wheel, right? Evan, that lib will allow me to create my own packets, but which socket do i send it to? Thats been the question all along. I think this is getting really interesting :) Tx, Vinod. On Wed, 22 May 2002 Miguel Cruz wrote : I don't think you're going to get Apache to hand you the socket. However, you can write a program using the standalone (CGI) PHP interpreter that will act like a server - check out http://php.net/socket_create_listen for more info. You could redirect from your standard web server to your listening PHP app running on another port. You'll then have to implement at least a subset of the HTTP protocol in order to get browsers to talk to you. Unfortunately, since you can't - to the best of my knowledge - fork a PHP program, you're going to have to do your own homebrew threading which will make life slightly complicated. miguel On 22 May 2002, Vinod Panicker wrote: It still seems like I havent made the problem clear enough. I am aware of the print(), echo() and flush() functions and what they do. It does not fit in as a solution. Let me explain my problem more elaborately - The client calls a PHP script, script_a.php on the Apache web server, using a Keep-Alive connection. The script returns some response to the client which it uses. Now since the connection is a Keep-alive, apache still has it open for reading and writing. When the client wants to call other scripts, it just sends the request over the same connection. Now the thing is that if the server needs to send some ASYNCHRONOUS data to the client, without the client requesting for anything, a normal PHP script wont be able to do it, since the script would get executed by the web server ONLY on a client request (coz thats the way HTTP works). Now what i was thinking was - if i could get hold of the socket that is being used by apache to send data to the client, I could effectively write() to it, from a C++ app or a PHP script (which gets invoked from lets say another server). print(), echo() etc
Re: [PHP] Full-Duplex communication
Not to be argumentative, but what you're trying to do is just so amazingly much more complicated than any of my suggestions. Maybe I haven't communicated it well, it maybe there's some requirement to your project that I don't understand. Why not just write a listener in PHP and redirect to it? It's basically no work. Handcrafting packets for this purpose is like building a car out of paper clips and cat hair because the car that's freely available to you is red - and you don't like the color red because your old girlfriend used to wear it a lot. miguel On 23 May 2002, Vinod Panicker wrote: What you said did make sense, and complements my knowledge of sockets. But what i'm not sure of is this - if i construct my own packet and send it across, presuming that i do have the ip address and port number of the client on which it is reading, will the client accept it as a legitimate packet? I suspect that since the packets would be having some kind of session identifier / sequence number. Getting the ip address and port number is no problem. I already have that getting stored on the server. But from what i know of sockets, i'm sceptical if the client will accept the packet. Guess the only way to go ahead is to try this out. Would someone pls pls pls write a PHP interface to libnet?? Tx, Vinod. On Thu, 23 May 2002 Evan Nemerson wrote : You're right- this is getting interesting ;) http://www.packetfactory.net/libnet/manual/4.html#s4.1.5 Unless I'm mistaken, you don't need to actually hijack the socket- you merely need to write to the network. Check out section 3.1 of RFC 793. There is source and destination port- that is how they are routed. Okay anyone PLEASE correct me if i'm wrong... My understanding is a socket is an interface to the kernel. So basically, you talk to a socket, which the kernel associates with source and destination ports, and destination IP address. Thats why you can just write to a socket instead of explicitly stating all the information. The kernel then sends out then creates the packet and send it to the destination IP. libnet would allow you to bypass the socket phase, and manually create a socket. Think of a socket as a GUI for the network, and libnet is like a console ;) Hope that helps, and once again anyone PLEASE correct any inaccuracies, since I want to know. On Tuesday 21 May 2002 23:53 pm, Vinod Panicker wrote: Thanks for the reply Miguel, but here i'm not trying to implement my own multi-threaded server - exactly the reason why i'm using Apache / PHP. I could have made a listening server which is based on a multi-threaded or multi-forked model, but the time and complexities involved would be huge. Thats why I chose Apache / PHP. Now if what i'm asking for can be done, developers can easily leverage existing efficient server technologies (Apache) to build their own App servers. I know that there is no existing function in PHP that would allow it to retrieve the socket from Apache ;), all i'm asking for is a hack that would allow me to do it. I thought that i'd just as well post it on the mailing list before diving into the source code and trying to figure out for myself. No point trying to re-invent the wheel, right? Evan, that lib will allow me to create my own packets, but which socket do i send it to? Thats been the question all along. I think this is getting really interesting :) Tx, Vinod. On Wed, 22 May 2002 Miguel Cruz wrote : I don't think you're going to get Apache to hand you the socket. However, you can write a program using the standalone (CGI) PHP interpreter that will act like a server - check out http://php.net/socket_create_listen for more info. You could redirect from your standard web server to your listening PHP app running on another port. You'll then have to implement at least a subset of the HTTP protocol in order to get browsers to talk to you. Unfortunately, since you can't - to the best of my knowledge - fork a PHP program, you're going to have to do your own homebrew threading which will make life slightly complicated. miguel On 22 May 2002, Vinod Panicker wrote: It still seems like I havent made the problem clear enough. I am aware of the print(), echo() and flush() functions and what they do. It does not fit in as a solution. Let me explain my problem more elaborately - The client calls a PHP script, script_a.php on the Apache web server, using a Keep-Alive connection. The script returns some response to the client which it uses. Now since the connection is a Keep-alive, apache still has it open for reading and writing. When the client
Re: Re: [PHP] Full-Duplex communication
LOL.. I like the color red BTW. Let me explain my project more in detail. This system is an Instant messaging system, with the backed running on apache / php / mysql. The front end client is a COM component that communicates with the backend, and interfaces with an MFC app. Now since Instant messaging requires that the server should be able to send asynchronous messages to the client (Presence, IM's, notifications, etc), and HTTP does not allow asynchronous communication, the only solution is to have the client poll the server for messages. Now i know that apache / php is not a good solution for an instant messaging server, but we needed it to be ready in a months time, and php is so amazing that we could get it up and running so fast. But it meant that we have to live with latency between messages because of the polling. So i was thinking if there was some way in which i could avoid the polling and send data asynchronously to the client (Pls refer to my previous posts). Thats why i was looking at a way in which i could get hold of the socket to the client, so i could use it to send data directly. Tx, Vinod. On Fri, 24 May 2002 Miguel Cruz wrote : Not to be argumentative, but what you're trying to do is just so amazingly much more complicated than any of my suggestions. Maybe I haven't communicated it well, it maybe there's some requirement to your project that I don't understand. Why not just write a listener in PHP and redirect to it? It's basically no work. Handcrafting packets for this purpose is like building a car out of paper clips and cat hair because the car that's freely available to you is red - and you don't like the color red because your old girlfriend used to wear it a lot. miguel On 23 May 2002, Vinod Panicker wrote: What you said did make sense, and complements my knowledge of sockets. But what i'm not sure of is this - if i construct my own packet and send it across, presuming that i do have the ip address and port number of the client on which it is reading, will the client accept it as a legitimate packet? I suspect that since the packets would be having some kind of session identifier / sequence number. Getting the ip address and port number is no problem. I already have that getting stored on the server. But from what i know of sockets, i'm sceptical if the client will accept the packet. Guess the only way to go ahead is to try this out. Would someone pls pls pls write a PHP interface to libnet?? Tx, Vinod. On Thu, 23 May 2002 Evan Nemerson wrote : You're right- this is getting interesting ;) http://www.packetfactory.net/libnet/manual/4.html#s4.1.5 Unless I'm mistaken, you don't need to actually hijack the socket- you merely need to write to the network. Check out section 3.1 of RFC 793. There is source and destination port- that is how they are routed. Okay anyone PLEASE correct me if i'm wrong... My understanding is a socket is an interface to the kernel. So basically, you talk to a socket, which the kernel associates with source and destination ports, and destination IP address. Thats why you can just write to a socket instead of explicitly stating all the information. The kernel then sends out then creates the packet and send it to the destination IP. libnet would allow you to bypass the socket phase, and manually create a socket. Think of a socket as a GUI for the network, and libnet is like a console ;) Hope that helps, and once again anyone PLEASE correct any inaccuracies, since I want to know. On Tuesday 21 May 2002 23:53 pm, Vinod Panicker wrote: Thanks for the reply Miguel, but here i'm not trying to implement my own multi-threaded server - exactly the reason why i'm using Apache / PHP. I could have made a listening server which is based on a multi-threaded or multi-forked model, but the time and complexities involved would be huge. Thats why I chose Apache / PHP. Now if what i'm asking for can be done, developers can easily leverage existing efficient server technologies (Apache) to build their own App servers. I know that there is no existing function in PHP that would allow it to retrieve the socket from Apache ;), all i'm asking for is a hack that would allow me to do it. I thought that i'd just as well post it on the mailing list before diving into the source code and trying to figure out for myself. No point trying to re-invent the wheel, right? Evan, that lib will allow me to create my own packets, but which socket do i send it to? Thats been the question all along. I think this is getting really interesting :) Tx, Vinod. On Wed, 22 May 2002 Miguel Cruz wrote : I don't think you're going to get Apache to hand you the socket.
Re: Re: [PHP] Full-Duplex communication
Vinod, Interesting... Okay unless I'm mistaken, what you want to do can't be accomplished through PHP. However, you may want to take a look at libnet. http://www.packetfactory.net/Projects/Libnet/ I've always wanted someone to create a PHP interface for this- unfortunatly my C isn't quite there yet, but I'm working on it... Have fun! On Tuesday 21 May 2002 22:55 pm, Vinod Panicker wrote: Hi, It still seems like I havent made the problem clear enough. I am aware of the print(), echo() and flush() functions and what they do. It does not fit in as a solution. Let me explain my problem more elaborately - The client calls a PHP script, script_a.php on the Apache web server, using a Keep-Alive connection. The script returns some response to the client which it uses. Now since the connection is a Keep-alive, apache still has it open for reading and writing. When the client wants to call other scripts, it just sends the request over the same connection. Now the thing is that if the server needs to send some ASYNCHRONOUS data to the client, without the client requesting for anything, a normal PHP script wont be able to do it, since the script would get executed by the web server ONLY on a client request (coz thats the way HTTP works). Now what i was thinking was - if i could get hold of the socket that is being used by apache to send data to the client, I could effectively write() to it, from a C++ app or a PHP script (which gets invoked from lets say another server). print(), echo() etc are functions that write to the output stream, which is opened as a result of the clients request, by the web server. I want the ability to write to a socket thats been created earlier - i want to steal it from Apache, so that i can use it when and where i like. Functions like echo() and print() are not going to work here, i will have to use write() so that i can specify the socket to which the data has to be written! Hope the problem is understood now. Now for your question - When the client wants to send data to the server, it just has to open a socket connection with the web server, and issue a GET or a POST request! if the connection is a keep-alive connection, and it has already been created, the client just has to do a GET or a POST without the need to connect(). This mechanism, where the client frequently connects() to the server and checks for messages is called polling. One way of reducing the high overhead of this is to reuse the connection by using a keep-alive connection. A still better improvement would be to remove the need for a poll altogether, by doing something (thats what my question is all about) on the server so that it can send data asynchronously to the server. Tx, Vinod. On Wed, 22 May 2002 Bogdan Stancescu wrote : For your specific problem, I think Mr. Lemos has provided a viable solution (using print() or echo() and flush() whenever you need to, instead of grabbing the socket and write() to it). My problem however is how you envision solving the communication the other way around (i.e. when the CLIENT wants to send data to the server). Bogdan Vinod Panicker wrote: Hi, Tx for your very prompt reply. Yeah, I'll post the solution as soon as I find it someplace. Let me outline the problem in more detail - Client (VC++) calls a PHP script on the server, specifies the connection type as Keep-Alive. The PHP script, somehow (still a big question) gets the socket on which the apache server has received the client request (so that it can send data to the client later) and stores it in a database. Now whenever another PHP script wants to send data asynchronously to the client, it gets the socket from the database, and just calls a write() on it. Since the connection is still open (Keep-Alive), the client receives the information, and doesnt have to poll the server periodically. The application of this is indeed destined for a messaging product, and could benefit a lot of other areas as well. The only thing that is needed is the socket from apache. Someone somewhere knows how to get this done, i'm sure :) Possibly a hack into the PHP module can get this done, i'm open to suggestions. Tx, Vinod. On Tue, 21 May 2002 Bogdan Stancescu wrote : Hi! I'm looking for an answer to your questions as well, so if you do find a solution on other lists, could you please post it here as well? Regarding the issue, your proposal wouldn't make for full-duplex as far as I understand since I don't see how the client would be able to send any data on the same connection _after_ getting connected. What are you using on the other end of the pipe (on the client)? Plain HTML? Flash? Java? Something else? Bogdan Vinod Panicker wrote: Hi, We have developed a client-server application where the server needs to send asynchronous data to the client. Now since we are using
Re: Re: [PHP] Full-Duplex communication
I don't think you're going to get Apache to hand you the socket. However, you can write a program using the standalone (CGI) PHP interpreter that will act like a server - check out http://php.net/socket_create_listen for more info. You could redirect from your standard web server to your listening PHP app running on another port. You'll then have to implement at least a subset of the HTTP protocol in order to get browsers to talk to you. Unfortunately, since you can't - to the best of my knowledge - fork a PHP program, you're going to have to do your own homebrew threading which will make life slightly complicated. miguel On 22 May 2002, Vinod Panicker wrote: It still seems like I havent made the problem clear enough. I am aware of the print(), echo() and flush() functions and what they do. It does not fit in as a solution. Let me explain my problem more elaborately - The client calls a PHP script, script_a.php on the Apache web server, using a Keep-Alive connection. The script returns some response to the client which it uses. Now since the connection is a Keep-alive, apache still has it open for reading and writing. When the client wants to call other scripts, it just sends the request over the same connection. Now the thing is that if the server needs to send some ASYNCHRONOUS data to the client, without the client requesting for anything, a normal PHP script wont be able to do it, since the script would get executed by the web server ONLY on a client request (coz thats the way HTTP works). Now what i was thinking was - if i could get hold of the socket that is being used by apache to send data to the client, I could effectively write() to it, from a C++ app or a PHP script (which gets invoked from lets say another server). print(), echo() etc are functions that write to the output stream, which is opened as a result of the clients request, by the web server. I want the ability to write to a socket thats been created earlier - i want to steal it from Apache, so that i can use it when and where i like. Functions like echo() and print() are not going to work here, i will have to use write() so that i can specify the socket to which the data has to be written! Hope the problem is understood now. Now for your question - When the client wants to send data to the server, it just has to open a socket connection with the web server, and issue a GET or a POST request! if the connection is a keep-alive connection, and it has already been created, the client just has to do a GET or a POST without the need to connect(). This mechanism, where the client frequently connects() to the server and checks for messages is called polling. One way of reducing the high overhead of this is to reuse the connection by using a keep-alive connection. A still better improvement would be to remove the need for a poll altogether, by doing something (thats what my question is all about) on the server so that it can send data asynchronously to the server. Tx, Vinod. On Wed, 22 May 2002 Bogdan Stancescu wrote : For your specific problem, I think Mr. Lemos has provided a viable solution (using print() or echo() and flush() whenever you need to, instead of grabbing the socket and write() to it). My problem however is how you envision solving the communication the other way around (i.e. when the CLIENT wants to send data to the server). Bogdan Vinod Panicker wrote: Hi, Tx for your very prompt reply. Yeah, I'll post the solution as soon as I find it someplace. Let me outline the problem in more detail - Client (VC++) calls a PHP script on the server, specifies the connection type as Keep-Alive. The PHP script, somehow (still a big question) gets the socket on which the apache server has received the client request (so that it can send data to the client later) and stores it in a database. Now whenever another PHP script wants to send data asynchronously to the client, it gets the socket from the database, and just calls a write() on it. Since the connection is still open (Keep-Alive), the client receives the information, and doesnt have to poll the server periodically. The application of this is indeed destined for a messaging product, and could benefit a lot of other areas as well. The only thing that is needed is the socket from apache. Someone somewhere knows how to get this done, i'm sure :) Possibly a hack into the PHP module can get this done, i'm open to suggestions. Tx, Vinod. On Tue, 21 May 2002 Bogdan Stancescu wrote : Hi! I'm looking for an answer to your questions as well, so if you do find a solution on other lists, could you please post it here as well? Regarding the issue, your proposal wouldn't make for full-duplex as far as I understand since I don't see how the client would be able to send any data on the same
Re: Re: [PHP] Full-Duplex communication
1st thing: sorry about the double-post. i don't know why that happened. If this one gets double posted too, i apologize in advance. 2nd: php.net/pcntl On Tuesday 21 May 2002 23:30 pm, Miguel Cruz wrote: I don't think you're going to get Apache to hand you the socket. However, you can write a program using the standalone (CGI) PHP interpreter that will act like a server - check out http://php.net/socket_create_listen for more info. You could redirect from your standard web server to your listening PHP app running on another port. You'll then have to implement at least a subset of the HTTP protocol in order to get browsers to talk to you. Unfortunately, since you can't - to the best of my knowledge - fork a PHP program, you're going to have to do your own homebrew threading which will make life slightly complicated. miguel On 22 May 2002, Vinod Panicker wrote: It still seems like I havent made the problem clear enough. I am aware of the print(), echo() and flush() functions and what they do. It does not fit in as a solution. Let me explain my problem more elaborately - The client calls a PHP script, script_a.php on the Apache web server, using a Keep-Alive connection. The script returns some response to the client which it uses. Now since the connection is a Keep-alive, apache still has it open for reading and writing. When the client wants to call other scripts, it just sends the request over the same connection. Now the thing is that if the server needs to send some ASYNCHRONOUS data to the client, without the client requesting for anything, a normal PHP script wont be able to do it, since the script would get executed by the web server ONLY on a client request (coz thats the way HTTP works). Now what i was thinking was - if i could get hold of the socket that is being used by apache to send data to the client, I could effectively write() to it, from a C++ app or a PHP script (which gets invoked from lets say another server). print(), echo() etc are functions that write to the output stream, which is opened as a result of the clients request, by the web server. I want the ability to write to a socket thats been created earlier - i want to steal it from Apache, so that i can use it when and where i like. Functions like echo() and print() are not going to work here, i will have to use write() so that i can specify the socket to which the data has to be written! Hope the problem is understood now. Now for your question - When the client wants to send data to the server, it just has to open a socket connection with the web server, and issue a GET or a POST request! if the connection is a keep-alive connection, and it has already been created, the client just has to do a GET or a POST without the need to connect(). This mechanism, where the client frequently connects() to the server and checks for messages is called polling. One way of reducing the high overhead of this is to reuse the connection by using a keep-alive connection. A still better improvement would be to remove the need for a poll altogether, by doing something (thats what my question is all about) on the server so that it can send data asynchronously to the server. Tx, Vinod. On Wed, 22 May 2002 Bogdan Stancescu wrote : For your specific problem, I think Mr. Lemos has provided a viable solution (using print() or echo() and flush() whenever you need to, instead of grabbing the socket and write() to it). My problem however is how you envision solving the communication the other way around (i.e. when the CLIENT wants to send data to the server). Bogdan Vinod Panicker wrote: Hi, Tx for your very prompt reply. Yeah, I'll post the solution as soon as I find it someplace. Let me outline the problem in more detail - Client (VC++) calls a PHP script on the server, specifies the connection type as Keep-Alive. The PHP script, somehow (still a big question) gets the socket on which the apache server has received the client request (so that it can send data to the client later) and stores it in a database. Now whenever another PHP script wants to send data asynchronously to the client, it gets the socket from the database, and just calls a write() on it. Since the connection is still open (Keep-Alive), the client receives the information, and doesnt have to poll the server periodically. The application of this is indeed destined for a messaging product, and could benefit a lot of other areas as well. The only thing that is needed is the socket from apache. Someone somewhere knows how to get this done, i'm sure :) Possibly a hack into the PHP module can get this done, i'm open to suggestions. Tx, Vinod. On Tue, 21 May 2002 Bogdan Stancescu wrote : Hi! I'm looking for an answer to your questions as well, so if you
Re: Re: [PHP] Full-Duplex communication
Ah, yes - http://php.net/pcntl_fork Well there you go, then - everything required to create a server in PHP. miguel On Tue, 21 May 2002, Evan Nemerson wrote: 1st thing: sorry about the double-post. i don't know why that happened. If this one gets double posted too, i apologize in advance. 2nd: php.net/pcntl On Tuesday 21 May 2002 23:30 pm, Miguel Cruz wrote: I don't think you're going to get Apache to hand you the socket. However, you can write a program using the standalone (CGI) PHP interpreter that will act like a server - check out http://php.net/socket_create_listen for more info. You could redirect from your standard web server to your listening PHP app running on another port. You'll then have to implement at least a subset of the HTTP protocol in order to get browsers to talk to you. Unfortunately, since you can't - to the best of my knowledge - fork a PHP program, you're going to have to do your own homebrew threading which will make life slightly complicated. miguel On 22 May 2002, Vinod Panicker wrote: It still seems like I havent made the problem clear enough. I am aware of the print(), echo() and flush() functions and what they do. It does not fit in as a solution. Let me explain my problem more elaborately - The client calls a PHP script, script_a.php on the Apache web server, using a Keep-Alive connection. The script returns some response to the client which it uses. Now since the connection is a Keep-alive, apache still has it open for reading and writing. When the client wants to call other scripts, it just sends the request over the same connection. Now the thing is that if the server needs to send some ASYNCHRONOUS data to the client, without the client requesting for anything, a normal PHP script wont be able to do it, since the script would get executed by the web server ONLY on a client request (coz thats the way HTTP works). Now what i was thinking was - if i could get hold of the socket that is being used by apache to send data to the client, I could effectively write() to it, from a C++ app or a PHP script (which gets invoked from lets say another server). print(), echo() etc are functions that write to the output stream, which is opened as a result of the clients request, by the web server. I want the ability to write to a socket thats been created earlier - i want to steal it from Apache, so that i can use it when and where i like. Functions like echo() and print() are not going to work here, i will have to use write() so that i can specify the socket to which the data has to be written! Hope the problem is understood now. Now for your question - When the client wants to send data to the server, it just has to open a socket connection with the web server, and issue a GET or a POST request! if the connection is a keep-alive connection, and it has already been created, the client just has to do a GET or a POST without the need to connect(). This mechanism, where the client frequently connects() to the server and checks for messages is called polling. One way of reducing the high overhead of this is to reuse the connection by using a keep-alive connection. A still better improvement would be to remove the need for a poll altogether, by doing something (thats what my question is all about) on the server so that it can send data asynchronously to the server. Tx, Vinod. On Wed, 22 May 2002 Bogdan Stancescu wrote : For your specific problem, I think Mr. Lemos has provided a viable solution (using print() or echo() and flush() whenever you need to, instead of grabbing the socket and write() to it). My problem however is how you envision solving the communication the other way around (i.e. when the CLIENT wants to send data to the server). Bogdan Vinod Panicker wrote: Hi, Tx for your very prompt reply. Yeah, I'll post the solution as soon as I find it someplace. Let me outline the problem in more detail - Client (VC++) calls a PHP script on the server, specifies the connection type as Keep-Alive. The PHP script, somehow (still a big question) gets the socket on which the apache server has received the client request (so that it can send data to the client later) and stores it in a database. Now whenever another PHP script wants to send data asynchronously to the client, it gets the socket from the database, and just calls a write() on it. Since the connection is still open (Keep-Alive), the client receives the information, and doesnt have to poll the server periodically. The application of this is indeed destined for a messaging product, and could benefit a lot of other areas as well. The only thing that is needed is the socket from apache. Someone somewhere
Re: Re: Re: [PHP] Full-Duplex communication
Thanks for the reply Miguel, but here i'm not trying to implement my own multi-threaded server - exactly the reason why i'm using Apache / PHP. I could have made a listening server which is based on a multi-threaded or multi-forked model, but the time and complexities involved would be huge. Thats why I chose Apache / PHP. Now if what i'm asking for can be done, developers can easily leverage existing efficient server technologies (Apache) to build their own App servers. I know that there is no existing function in PHP that would allow it to retrieve the socket from Apache ;), all i'm asking for is a hack that would allow me to do it. I thought that i'd just as well post it on the mailing list before diving into the source code and trying to figure out for myself. No point trying to re-invent the wheel, right? Evan, that lib will allow me to create my own packets, but which socket do i send it to? Thats been the question all along. I think this is getting really interesting :) Tx, Vinod. On Wed, 22 May 2002 Miguel Cruz wrote : I don't think you're going to get Apache to hand you the socket. However, you can write a program using the standalone (CGI) PHP interpreter that will act like a server - check out http://php.net/socket_create_listen for more info. You could redirect from your standard web server to your listening PHP app running on another port. You'll then have to implement at least a subset of the HTTP protocol in order to get browsers to talk to you. Unfortunately, since you can't - to the best of my knowledge - fork a PHP program, you're going to have to do your own homebrew threading which will make life slightly complicated. miguel On 22 May 2002, Vinod Panicker wrote: It still seems like I havent made the problem clear enough. I am aware of the print(), echo() and flush() functions and what they do. It does not fit in as a solution. Let me explain my problem more elaborately - The client calls a PHP script, script_a.php on the Apache web server, using a Keep-Alive connection. The script returns some response to the client which it uses. Now since the connection is a Keep-alive, apache still has it open for reading and writing. When the client wants to call other scripts, it just sends the request over the same connection. Now the thing is that if the server needs to send some ASYNCHRONOUS data to the client, without the client requesting for anything, a normal PHP script wont be able to do it, since the script would get executed by the web server ONLY on a client request (coz thats the way HTTP works). Now what i was thinking was - if i could get hold of the socket that is being used by apache to send data to the client, I could effectively write() to it, from a C++ app or a PHP script (which gets invoked from lets say another server). print(), echo() etc are functions that write to the output stream, which is opened as a result of the clients request, by the web server. I want the ability to write to a socket thats been created earlier - i want to steal it from Apache, so that i can use it when and where i like. Functions like echo() and print() are not going to work here, i will have to use write() so that i can specify the socket to which the data has to be written! Hope the problem is understood now. Now for your question - When the client wants to send data to the server, it just has to open a socket connection with the web server, and issue a GET or a POST request! if the connection is a keep-alive connection, and it has already been created, the client just has to do a GET or a POST without the need to connect(). This mechanism, where the client frequently connects() to the server and checks for messages is called polling. One way of reducing the high overhead of this is to reuse the connection by using a keep-alive connection. A still better improvement would be to remove the need for a poll altogether, by doing something (thats what my question is all about) on the server so that it can send data asynchronously to the server. Tx, Vinod. On Wed, 22 May 2002 Bogdan Stancescu wrote : For your specific problem, I think Mr. Lemos has provided a viable solution (using print() or echo() and flush() whenever you need to, instead of grabbing the socket and write() to it). My problem however is how you envision solving the communication the other way around (i.e. when the CLIENT wants to send data to the server). Bogdan Vinod Panicker wrote: Hi, Tx for your very prompt reply. Yeah, I'll post the solution as soon as I find it someplace. Let me outline the problem in more detail - Client (VC++) calls a PHP script on the server, specifies the connection type as Keep-Alive. The PHP script, somehow (still a big question) gets the socket on which the apache server
Re: Re: [PHP] Full-Duplex communication
At 5:55 AM + 22/5/02, Vinod Panicker wrote: I want the ability to write to a socket thats been created earlier - i want to steal it from Apache, so that i can use it when and where i like. Why not just keep your script running and have it send more data to the browser whenever it becomes available. The browser will add the new data to the page on display. With some clever use of DHTML you could probably make the existing content be updated with the new material. When a browser wants to trigger an update it will close the existing connection and open a new one. Your running script will be killed by apache and your new one would build a base page and start streaming the data in it's place. I see nothing here more complicated than a long-running script and perhaps sessions to manage the browser-initiated connections. ...Richard. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: Re: Re: [PHP] Full-Duplex communication
What i have at the other end is a Instant Messenger client :) Cant have the script running till the time the user logs out can i? And also, different activities are triggered on the server asynchronously (presence status, instant messages, notifications) which has to be sent to the client. Tx, Vinod. On Wed, 22 May 2002 Richard Archer wrote : At 5:55 AM + 22/5/02, Vinod Panicker wrote: I want the ability to write to a socket thats been created earlier - i want to steal it from Apache, so that i can use it when and where i like. Why not just keep your script running and have it send more data to the browser whenever it becomes available. The browser will add the new data to the page on display. With some clever use of DHTML you could probably make the existing content be updated with the new material. When a browser wants to trigger an update it will close the existing connection and open a new one. Your running script will be killed by apache and your new one would build a base page and start streaming the data in it's place. I see nothing here more complicated than a long-running script and perhaps sessions to manage the browser-initiated connections. ...Richard. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php _ Click below to visit monsterindia.com and review jobs in India or Abroad http://monsterindia.rediff.com/jobs -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: Re: Re: [PHP] Full-Duplex communication
At 7:01 AM + 22/5/02, Vinod Panicker wrote: What i have at the other end is a Instant Messenger client :) Which is presumably accepting some form of HTML or at least a stream of data sent over HTTP and displaying the data. If it's notdoing this, Apache is almost certainly the wrong platform for the server!! So, just keep on streaming the data to the client. Keep the script running and keep on sending the message. If you need to have the client send a status stream to the server, have it trigger a new message which will be received by a second script on the server. This script would insert the new status for that client in a database and the long-running script would periodically poll the database and act upon whatever status info it finds. Might not be instant update, but that's dependent on how often you poll for change of status. Cant have the script running till the time the user logs out can i? Why not? You're planning on sending data to them until they log out, so why not keep one script running? ...R. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Full-Duplex communication
Hi Richard, Thanks for your suggestion. Yes, Apache is the wrong platform for the server. What would be ideal is a custom designed TCP based multi-threaded server. Since we had lots of constraints, we went in for Apache / PHP. What i'm trying to do is to reduce the number of compromises being made in this architecture. If i have a long running script, the script is still polling the database, wasting precious server CPU cycles. Having an open socket on which the server calls select() is much less CPU intensive. Instant is how the response should be. Thats why i'm clamouring for the socket so that i can send data directly to the client, from a C++ binary or maybe another script. And to have the script running for hours, i would have to change the script timeout to a ludicrous setting, which would leave open many more possiblities for other problems. Tx, Vinod. On Wed, 22 May 2002 Richard Archer wrote : At 7:01 AM + 22/5/02, Vinod Panicker wrote: What i have at the other end is a Instant Messenger client :) Which is presumably accepting some form of HTML or at least a stream of data sent over HTTP and displaying the data. If it's notdoing this, Apache is almost certainly the wrong platform for the server!! So, just keep on streaming the data to the client. Keep the script running and keep on sending the message. If you need to have the client send a status stream to the server, have it trigger a new message which will be received by a second script on the server. This script would insert the new status for that client in a database and the long-running script would periodically poll the database and act upon whatever status info it finds. Might not be instant update, but that's dependent on how often you poll for change of status. Cant have the script running till the time the user logs out can i? Why not? You're planning on sending data to them until they log out, so why not keep one script running? ...R. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php _ Click below to visit monsterindia.com and review jobs in India or Abroad http://monsterindia.rediff.com/jobs -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Full-Duplex communication
On 22 May 2002, Vinod Panicker wrote: Instant is how the response should be. Thats why i'm clamouring for the socket so that i can send data directly to the client, from a C++ binary or maybe another script. If you're willing to write C code, I'd suggest posing your question in comp.infosystems.www.servers.unix, where people will be happy to tell you about Apache APIs that may be of use. miguel -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Full-Duplex communication
On Wed, 22 May 2002, Miguel Cruz wrote: On 22 May 2002, Vinod Panicker wrote: Instant is how the response should be. Thats why i'm clamouring for the socket so that i can send data directly to the client, from a C++ binary or maybe another script. If you're willing to write C code, I'd suggest posing your question in comp.infosystems.www.servers.unix, where people will be happy to tell you about Apache APIs that may be of use. And, to be honest, the listen-fork model is so simple that it's not as if you're doing a whole lot of work implementing it in PHP. You're looking at about 15 lines of code for a model case. miguel -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: Re: [PHP] Full-Duplex communication
Just subscribed to comp.infosystems True, the listen-fork model would hardly be any lines of code, but the changes that will have to be done to the client and the server would be enormous. We are talking abt a production system here which needs to be optimised. I cant honestly go ahead for a solution that would involve such a huge re-write :( though i'd love to do that using PHP. Just wanted to take the chance to give a huge CONGRATS to the PHP dev team for making such an AMAZING server-side scripting language. Beats the shit out of anything else (personal opinion :)) And looking at the pace at which the development and feature additions are going on, wont be long before we have our very own PHP-OS !!! (for all i know, it might be already there) Keep up the great work guys! Tx, Vinod. On Wed, 22 May 2002 Miguel Cruz wrote : On Wed, 22 May 2002, Miguel Cruz wrote: On 22 May 2002, Vinod Panicker wrote: Instant is how the response should be. Thats why i'm clamouring for the socket so that i can send data directly to the client, from a C++ binary or maybe another script. If you're willing to write C code, I'd suggest posing your question in comp.infosystems.www.servers.unix, where people will be happy to tell you about Apache APIs that may be of use. And, to be honest, the listen-fork model is so simple that it's not as if you're doing a whole lot of work implementing it in PHP. You're looking at about 15 lines of code for a model case. miguel -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php _ Click below to visit monsterindia.com and review jobs in India or Abroad http://monsterindia.rediff.com/jobs -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: Re: Re: [PHP] Full-Duplex communication
You're right- this is getting interesting ;) http://www.packetfactory.net/libnet/manual/4.html#s4.1.5 Unless I'm mistaken, you don't need to actually hijack the socket- you merely need to write to the network. Check out section 3.1 of RFC 793. There is source and destination port- that is how they are routed. Okay anyone PLEASE correct me if i'm wrong... My understanding is a socket is an interface to the kernel. So basically, you talk to a socket, which the kernel associates with source and destination ports, and destination IP address. Thats why you can just write to a socket instead of explicitly stating all the information. The kernel then sends out then creates the packet and send it to the destination IP. libnet would allow you to bypass the socket phase, and manually create a socket. Think of a socket as a GUI for the network, and libnet is like a console ;) Hope that helps, and once again anyone PLEASE correct any inaccuracies, since I want to know. On Tuesday 21 May 2002 23:53 pm, Vinod Panicker wrote: Thanks for the reply Miguel, but here i'm not trying to implement my own multi-threaded server - exactly the reason why i'm using Apache / PHP. I could have made a listening server which is based on a multi-threaded or multi-forked model, but the time and complexities involved would be huge. Thats why I chose Apache / PHP. Now if what i'm asking for can be done, developers can easily leverage existing efficient server technologies (Apache) to build their own App servers. I know that there is no existing function in PHP that would allow it to retrieve the socket from Apache ;), all i'm asking for is a hack that would allow me to do it. I thought that i'd just as well post it on the mailing list before diving into the source code and trying to figure out for myself. No point trying to re-invent the wheel, right? Evan, that lib will allow me to create my own packets, but which socket do i send it to? Thats been the question all along. I think this is getting really interesting :) Tx, Vinod. On Wed, 22 May 2002 Miguel Cruz wrote : I don't think you're going to get Apache to hand you the socket. However, you can write a program using the standalone (CGI) PHP interpreter that will act like a server - check out http://php.net/socket_create_listen for more info. You could redirect from your standard web server to your listening PHP app running on another port. You'll then have to implement at least a subset of the HTTP protocol in order to get browsers to talk to you. Unfortunately, since you can't - to the best of my knowledge - fork a PHP program, you're going to have to do your own homebrew threading which will make life slightly complicated. miguel On 22 May 2002, Vinod Panicker wrote: It still seems like I havent made the problem clear enough. I am aware of the print(), echo() and flush() functions and what they do. It does not fit in as a solution. Let me explain my problem more elaborately - The client calls a PHP script, script_a.php on the Apache web server, using a Keep-Alive connection. The script returns some response to the client which it uses. Now since the connection is a Keep-alive, apache still has it open for reading and writing. When the client wants to call other scripts, it just sends the request over the same connection. Now the thing is that if the server needs to send some ASYNCHRONOUS data to the client, without the client requesting for anything, a normal PHP script wont be able to do it, since the script would get executed by the web server ONLY on a client request (coz thats the way HTTP works). Now what i was thinking was - if i could get hold of the socket that is being used by apache to send data to the client, I could effectively write() to it, from a C++ app or a PHP script (which gets invoked from lets say another server). print(), echo() etc are functions that write to the output stream, which is opened as a result of the clients request, by the web server. I want the ability to write to a socket thats been created earlier - i want to steal it from Apache, so that i can use it when and where i like. Functions like echo() and print() are not going to work here, i will have to use write() so that i can specify the socket to which the data has to be written! Hope the problem is understood now. Now for your question - When the client wants to send data to the server, it just has to open a socket connection with the web server, and issue a GET or a POST request! if the connection is a keep-alive connection, and it has already been created, the client just has to do a GET or a POST without the need to connect(). This mechanism, where the client
Re: [PHP] Full-Duplex communication
Hi! I'm looking for an answer to your questions as well, so if you do find a solution on other lists, could you please post it here as well? Regarding the issue, your proposal wouldn't make for full-duplex as far as I understand since I don't see how the client would be able to send any data on the same connection _after_ getting connected. What are you using on the other end of the pipe (on the client)? Plain HTML? Flash? Java? Something else? Bogdan Vinod Panicker wrote: Hi, We have developed a client-server application where the server needs to send asynchronous data to the client. Now since we are using Apache/PHP/MySQL, the client needs to poll the server periodically for information. I was thinking if there was some way to get around this basic problem. I understand that this is how things are supposed to work, but it would be just great if i could PUSH data from the server to the client, using HTTP. Since HTTP is a request/response based protocol, Apache would not send any data to the client asynchronously. So what i was thinking was - If i tell the server to allow Keep-Alive connections, and increase the timeout value and max requests, I would effectively have a constant TCP connection. Now the only problem would be of sending asynchronous data to the client. Solution? Here goes - If there was some way in which i could get hold of the file descriptor(socket) that is being used by apache to write data to the client, then i could, from a PHP script also send any data to the client using the socket functions of PHP since i already have the socket with me. This would mean that the client doesnt have to poll the server for data any more... and if the connection does get closed, the client could reconnect to the server asking for another keep-alive connection. Now I know that this is probably the wrong place to put such a query - maybe the apache list would have been better. But since I'm using PHP out here, i thought i'd give it a try. Does the solution sound very outlandish? Are there any pitfalls? And finally, how do i get hold of the socket? Tx in advance, Vinod. _ Click below to visit monsterindia.com and review jobs in India or Abroad http://monsterindia.rediff.com/jobs -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: Re: [PHP] Full-Duplex communication
Hi, Tx for your very prompt reply. Yeah, I'll post the solution as soon as I find it someplace. Let me outline the problem in more detail - Client (VC++) calls a PHP script on the server, specifies the connection type as Keep-Alive. The PHP script, somehow (still a big question) gets the socket on which the apache server has received the client request (so that it can send data to the client later) and stores it in a database. Now whenever another PHP script wants to send data asynchronously to the client, it gets the socket from the database, and just calls a write() on it. Since the connection is still open (Keep-Alive), the client receives the information, and doesnt have to poll the server periodically. The application of this is indeed destined for a messaging product, and could benefit a lot of other areas as well. The only thing that is needed is the socket from apache. Someone somewhere knows how to get this done, i'm sure :) Possibly a hack into the PHP module can get this done, i'm open to suggestions. Tx, Vinod. On Tue, 21 May 2002 Bogdan Stancescu wrote : Hi! I'm looking for an answer to your questions as well, so if you do find a solution on other lists, could you please post it here as well? Regarding the issue, your proposal wouldn't make for full-duplex as far as I understand since I don't see how the client would be able to send any data on the same connection _after_ getting connected. What are you using on the other end of the pipe (on the client)? Plain HTML? Flash? Java? Something else? Bogdan Vinod Panicker wrote: Hi, We have developed a client-server application where the server needs to send asynchronous data to the client. Now since we are using Apache/PHP/MySQL, the client needs to poll the server periodically for information. I was thinking if there was some way to get around this basic problem. I understand that this is how things are supposed to work, but it would be just great if i could PUSH data from the server to the client, using HTTP. Since HTTP is a request/response based protocol, Apache would not send any data to the client asynchronously. So what i was thinking was - If i tell the server to allow Keep-Alive connections, and increase the timeout value and max requests, I would effectively have a constant TCP connection. Now the only problem would be of sending asynchronous data to the client. Solution? Here goes - If there was some way in which i could get hold of the file descriptor(socket) that is being used by apache to write data to the client, then i could, from a PHP script also send any data to the client using the socket functions of PHP since i already have the socket with me. This would mean that the client doesnt have to poll the server for data any more... and if the connection does get closed, the client could reconnect to the server asking for another keep-alive connection. Now I know that this is probably the wrong place to put such a query - maybe the apache list would have been better. But since I'm using PHP out here, i thought i'd give it a try. Does the solution sound very outlandish? Are there any pitfalls? And finally, how do i get hold of the socket? Tx in advance, Vinod. _ Click below to visit monsterindia.com and review jobs in India or Abroad http://monsterindia.rediff.com/jobs _ Click below to visit monsterindia.com and review jobs in India or Abroad http://monsterindia.rediff.com/jobs -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Full-Duplex communication
For your specific problem, I think Mr. Lemos has provided a viable solution (using print() or echo() and flush() whenever you need to, instead of grabbing the socket and write() to it). My problem however is how you envision solving the communication the other way around (i.e. when the CLIENT wants to send data to the server). Bogdan Vinod Panicker wrote: Hi, Tx for your very prompt reply. Yeah, I'll post the solution as soon as I find it someplace. Let me outline the problem in more detail - Client (VC++) calls a PHP script on the server, specifies the connection type as Keep-Alive. The PHP script, somehow (still a big question) gets the socket on which the apache server has received the client request (so that it can send data to the client later) and stores it in a database. Now whenever another PHP script wants to send data asynchronously to the client, it gets the socket from the database, and just calls a write() on it. Since the connection is still open (Keep-Alive), the client receives the information, and doesnt have to poll the server periodically. The application of this is indeed destined for a messaging product, and could benefit a lot of other areas as well. The only thing that is needed is the socket from apache. Someone somewhere knows how to get this done, i'm sure :) Possibly a hack into the PHP module can get this done, i'm open to suggestions. Tx, Vinod. On Tue, 21 May 2002 Bogdan Stancescu wrote : Hi! I'm looking for an answer to your questions as well, so if you do find a solution on other lists, could you please post it here as well? Regarding the issue, your proposal wouldn't make for full-duplex as far as I understand since I don't see how the client would be able to send any data on the same connection _after_ getting connected. What are you using on the other end of the pipe (on the client)? Plain HTML? Flash? Java? Something else? Bogdan Vinod Panicker wrote: Hi, We have developed a client-server application where the server needs to send asynchronous data to the client. Now since we are using Apache/PHP/MySQL, the client needs to poll the server periodically for information. I was thinking if there was some way to get around this basic problem. I understand that this is how things are supposed to work, but it would be just great if i could PUSH data from the server to the client, using HTTP. Since HTTP is a request/response based protocol, Apache would not send any data to the client asynchronously. So what i was thinking was - If i tell the server to allow Keep-Alive connections, and increase the timeout value and max requests, I would effectively have a constant TCP connection. Now the only problem would be of sending asynchronous data to the client. Solution? Here goes - If there was some way in which i could get hold of the file descriptor(socket) that is being used by apache to write data to the client, then i could, from a PHP script also send any data to the client using the socket functions of PHP since i already have the socket with me. This would mean that the client doesnt have to poll the server for data any more... and if the connection does get closed, the client could reconnect to the server asking for another keep-alive connection. Now I know that this is probably the wrong place to put such a query - maybe the apache list would have been better. But since I'm using PHP out here, i thought i'd give it a try. Does the solution sound very outlandish? Are there any pitfalls? And finally, how do i get hold of the socket? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: Re: [PHP] Full-Duplex communication
Hi, It still seems like I havent made the problem clear enough. I am aware of the print(), echo() and flush() functions and what they do. It does not fit in as a solution. Let me explain my problem more elaborately - The client calls a PHP script, script_a.php on the Apache web server, using a Keep-Alive connection. The script returns some response to the client which it uses. Now since the connection is a Keep-alive, apache still has it open for reading and writing. When the client wants to call other scripts, it just sends the request over the same connection. Now the thing is that if the server needs to send some ASYNCHRONOUS data to the client, without the client requesting for anything, a normal PHP script wont be able to do it, since the script would get executed by the web server ONLY on a client request (coz thats the way HTTP works). Now what i was thinking was - if i could get hold of the socket that is being used by apache to send data to the client, I could effectively write() to it, from a C++ app or a PHP script (which gets invoked from lets say another server). print(), echo() etc are functions that write to the output stream, which is opened as a result of the clients request, by the web server. I want the ability to write to a socket thats been created earlier - i want to steal it from Apache, so that i can use it when and where i like. Functions like echo() and print() are not going to work here, i will have to use write() so that i can specify the socket to which the data has to be written! Hope the problem is understood now. Now for your question - When the client wants to send data to the server, it just has to open a socket connection with the web server, and issue a GET or a POST request! if the connection is a keep-alive connection, and it has already been created, the client just has to do a GET or a POST without the need to connect(). This mechanism, where the client frequently connects() to the server and checks for messages is called polling. One way of reducing the high overhead of this is to reuse the connection by using a keep-alive connection. A still better improvement would be to remove the need for a poll altogether, by doing something (thats what my question is all about) on the server so that it can send data asynchronously to the server. Tx, Vinod. On Wed, 22 May 2002 Bogdan Stancescu wrote : For your specific problem, I think Mr. Lemos has provided a viable solution (using print() or echo() and flush() whenever you need to, instead of grabbing the socket and write() to it). My problem however is how you envision solving the communication the other way around (i.e. when the CLIENT wants to send data to the server). Bogdan Vinod Panicker wrote: Hi, Tx for your very prompt reply. Yeah, I'll post the solution as soon as I find it someplace. Let me outline the problem in more detail - Client (VC++) calls a PHP script on the server, specifies the connection type as Keep-Alive. The PHP script, somehow (still a big question) gets the socket on which the apache server has received the client request (so that it can send data to the client later) and stores it in a database. Now whenever another PHP script wants to send data asynchronously to the client, it gets the socket from the database, and just calls a write() on it. Since the connection is still open (Keep-Alive), the client receives the information, and doesnt have to poll the server periodically. The application of this is indeed destined for a messaging product, and could benefit a lot of other areas as well. The only thing that is needed is the socket from apache. Someone somewhere knows how to get this done, i'm sure :) Possibly a hack into the PHP module can get this done, i'm open to suggestions. Tx, Vinod. On Tue, 21 May 2002 Bogdan Stancescu wrote : Hi! I'm looking for an answer to your questions as well, so if you do find a solution on other lists, could you please post it here as well? Regarding the issue, your proposal wouldn't make for full-duplex as far as I understand since I don't see how the client would be able to send any data on the same connection _after_ getting connected. What are you using on the other end of the pipe (on the client)? Plain HTML? Flash? Java? Something else? Bogdan Vinod Panicker wrote: Hi, We have developed a client-server application where the server needs to send asynchronous data to the client. Now since we are using Apache/PHP/MySQL, the client needs to poll the server periodically for information. I was thinking if there was some way to get around this basic problem. I understand that this is how things are supposed to work, but it would be just great if i could PUSH data from the server to the client, using HTTP. Since HTTP is a request/response based protocol, Apache would not send any data to the client asynchronously. So what i was thinking was - If i tell the
