fsockopen() has changed dramaticly in current CVS with the introduction of streams. Would you mind trying a snapshot to see if your problem still persists?

snaps.php.net/win32/

Thanks,
-Jason

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.

Sorry, I had posted some more feedback. Don't know where it is now. So I'll do again:

I tested that CVS build and the result was, that unread_bytes told me the number of bytes, containing the PHP internal socket buffer and not the number of bytes, available on that socket. And I think, that unread_bytes should exactly mean that. Otherwise it would be some less useful.

Well, that depends on how you use the information. If the goal is to detect a possible block(which looks like what your code is doing), then when that value is 0, there is no data left on the socket. The same is true if blocked is set, and if eof is set.

What would your reason be to look at the sytems buffer?

-Jason

I want to check the socket, whether there is data that must be read. Otherwise the script should do other things. At moment the situation is, that the script only can do other things, after read some data from the socket. The most popular thing, that requires this mechanism, is to write an IRC client with PHP, that can be used like cgi irc. Don't know whether is possible with any current php build for Linux, under Windows it wasn't possible with the builds from July 2002. I tried blocking and non blocking mode, but the stream reseted. So I prefered blocking mode, because the control about the socket is better.

The script only must know, whether there is data to read from the socket, so that a request to the socket doesn't stop the script, until there is some data.

unread_bytes is the number of bytes remaining in PHPs buffering layer after the last read.
If you have consumed all data from the buffer on a prior read, unread_bytes will remain at zero until you next read a chunk of data from the network.
So, unread_bytes should not be used to determine if more data is pending; you should use either:

a. feof() to detect end of file.
   Don't forget that you can use non-blocking mode here.

b. PHP 4.3 has a new function called stream_select() which
   behaves like socket_select() from the sockets extension,
   but works on all files returned by fopen() and
   fsockopen().  You can use it to test which files are
   ready for reading/writing and also specify a timeout.

PHP 4.3 is about to enter the release process, but you
can try a non-stable snapshot from
http://snaps.php.net/win32.
(It's probably best to wait a couple of hours, as some
important bug fixes have been made this morning).

--Wez.

feof() doesn't work with blocked sockets like flag for available data. When it is time to see if more data is available and feof() returns true that means that socket is actually closed.

Perhaps I can say where is a bug actually. When you write to a blocked socket with fwrite() it resets internal socket buffer and the next thing you'd like to know is when the data will be available. Now there's no way to get that info. You can try to execute a read operation and enter an endless loop waiting for the data to appear from the other end until either script timeout happened or somebody will send the data.