Re: 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

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