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. 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

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?

_________________________________________________________

Click below to visit monsterindia.com and review jobs in India or Abroad http://monsterindia.rediff.com/jobs