php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #18373 unread_bytes always 0
Submitted: 2002-07-16 12:35 UTC Modified: 2004-11-06 16:46 UTC
From: webmaster at darkenemy dot com Assigned:
Status: Not a bug Package: Sockets related
PHP Version: 4.2.1 OS: Windows Server Platform
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: webmaster at darkenemy dot com
New email:
PHP Version: OS:

 

 [2002-07-16 12:35 UTC] webmaster at darkenemy dot com
After creating a blocking socket with fsockopen, I entered an idle loop. I've checked the property unread_bytes of the array returned by socket_get_status. After I got a value of zero bytes, socket_get_status reports always an unread buffer of zero bytes, also when the server sends any data. I checked the server logs and I checked the script without checking socket status. Without checking the socket status, it works wonderful.

Sample script:

<?php

echo "<html><body><pre>\n";
set_time_limit(0);

$sock = fsockopen("localhost",6667,$errno,$errstr,30);  // Connecting to dummy ircd
fputs($sock,"NICK PreProcessor\r\n");
fputs($sock,"USER PHP localhost localhost :HyperText Pre Processor\r\n");

while (!feof($sock)) {           // Loop until connection will be closed
  $stat = socket_get_status($sock);
  $queue = $stat[unread_bytes];  // How many bytes to read from socket?
  if ($queue > 0) {
    $data = chop(fgets($sock,128));
    echo $data."\r\n";
    flush();
    $foo = split("[:]",$data);
    if ($foo[0] == "PING ") fputs($sock,"PONG :$foo[1]\r\n");
    $foo = split("[ ]",$data);
    if ($foo[1] == "005") fputs($sock,"JOIN #Channel\r\n");
    if ($foo[3] == ":die") fputs($sock,"QUIT :EOF\r\n");	// retrieved shutdown script
  } else {
    sleep(1); // Sleep one second and do other things
  }
}

fclose($sock);       // Good bye ...
echo "</pre></body></html>\n";

?>

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2002-07-24 16:31 UTC] 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




 [2002-09-11 11:37 UTC] 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-09-11 11:47 UTC] webmaster at darkenemy dot 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-25 09:19 UTC] 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-25 09:25 UTC] webmaster at darkenemy dot 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-10-05 09:12 UTC] wez@php.net
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.
 [2004-11-06 16:46 UTC] techtonik@php.net
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. 

 
PHP Copyright © 2001-2020 The PHP Group
All rights reserved.
Last updated: Fri Apr 03 21:01:23 2020 UTC