I am writing 2 PHP scripts to run from the command line on Win7, a server and a client.

The server calls stream_socket_server() to create the socket, bind and listen.A timer event invokes my monitorsocket() every second, which calls stream_socket_accept().If successful, it then calls stream_set_blocking($client, 1) , reads the client's greeting using fgets() and writes the server's greeting using fwrite() - so far it works OK.

It then calls fgets() to get the client's first message and should wait for a response, but it doesn't - straight away it says it didn't get a response and goes into its fail routine. It clearly says in http://php.net/manual/en/function.strea ... ocking.phpIn non-blocking mode an fgets() call will always return right away while in blocking mode it will wait for data to become available on the stream.

I wasn't testing stream_set_blocking(), but I've just added that now and it returns TRUE, and still fails on the fgets() .I had wondered whether the resource parameter should be the value returned from stream_socket_accept() or from stream_socket_server(), so I tried both, and it didn't make any difference.

The scripts use the wxPHP library, which has wrappers for wxWidgets, to create a GUI.This imposes an object-oriented structure on the scripts.

In an attempt to focus on the stream_ functions, I extracted just the lines for the connection, dropping the GUI and structure, and that works!

So the GUI structure is having some kind of effect, although everything discussed here has been going on in the one function, monitorsocket() . If there was some problem during the fgets() wait for data, I could go looking for it, but fgets() doesn't wait - see the timestamps

if you look into the documentation for stream_socket_accept, the second parameter for this function is timeout which is in seconds. Here you have given this as '1' second. Looks like this is getting timed out even before you receive any data.

What stream_socket_accept returns is a connection to the stream and not a client. So, it is better to change this return value from $client to $connection. And, the next line is just a "if"?. I think it should be "keep looping as long as there is a stream connection". So, i think this should be

Thanks for your perseverence.The 1 second is the time the accept function will wait for a connection attempt.When there isn't a connection attempt in that second, monitorsocket() returns 1 to the wxPHP timer that invoked it, and the timer provides the looping effect - 1 implies keep looping.

When there is a connection, the greetings are exchanged OK, (showing the connection hasn't timed out). It is the "next message" that doesn't get through.

UpdateI wonder if the error might be in the client script. Despite the text of the server's greeting getting through, perhaps the server's ownership of writing rights hasn't been released, so the client's attempt to write appears to go OK (isn't rejected straight away anyway) but the server isn't ready for it, so it fails in the server script.

Do you know how these stream functions operate under the skin? How does one get inside them and see what they're doing?

After doing a rewrite of the server and client scripts, but using the stream functions in the same way, the problem has magically disappeared and its now working OK.

In case it helps anyone else, to clarify: stream_get_line() in blocking mode will wait for a response, while in non-blocking mode it will return straight away. This is not documented at http://au1.php.net/manual/en/function.s ... t-line.php . The same is true for fgets(), which is also not documented. stream_set_blocking() documents it for fgets().