#18373 [Opn->Bgs]: unread_bytes always 0

From: Date: Sat, 05 Oct 2002 14:12:29 +0000
Subject: #18373 [Opn->Bgs]: unread_bytes always 0
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-21561@lists.php.net to get a copy of this message
 ID:               18373
 Updated by:       wez@php.net
 Reported By:      webmaster@darkenemy.com
-Status:           Open
+Status:           Bogus
 Bug Type:         Sockets related
 Operating System: Windows Server Platform
 PHP Version:      4.2.1
 New Comment:

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.


Previous Comments:
------------------------------------------------------------------------

[2002-09-25 09:25:10] webmaster@darkenemy.com

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.

------------------------------------------------------------------------

[2002-09-25 09:19:07] jason@php.net

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





------------------------------------------------------------------------

[2002-09-11 11:47:26] webmaster@darkenemy.com

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.

------------------------------------------------------------------------

[2002-09-11 11:37:46] sniper@php.net

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.



------------------------------------------------------------------------

[2002-07-24 16:31:09] jason@php.net

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





------------------------------------------------------------------------

The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
    http://bugs.php.net/18373

-- 
Edit this bug report at http://bugs.php.net/?id=18373&edit=1



Thread (8 messages)

« previous php.bugs (#21561) next »