php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Doc Bug #62394 socket_read non-blocking resets timeout with no data read
Submitted: 2012-06-22 10:31 UTC Modified: 2021-04-06 12:30 UTC
Votes:18
Avg. Score:3.5 ± 0.8
Reproduced:5 of 9 (55.6%)
Same Version:0 (0.0%)
Same OS:2 (40.0%)
From: sysfly at gmail dot com Assigned:
Status: Verified Package: Sockets related
PHP Version: 5.3.14 OS: Windows
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: sysfly at gmail dot com
New email:
PHP Version: OS:

 

 [2012-06-22 10:31 UTC] sysfly at gmail dot com
Description:
------------
If you call socket_read and it throws an error such as socket error 10035 then the 
connection will never timeout even if the remote side disconnects. Socket error 
10035 is thrown if data is not ready to be read (hasn't been sent) yet and is not 
really indicative of a disconnect or other fatal error.

Maybe there's a distinction to be made between fatal and nonfatal socket errors. 
Possibly have it return an empty string instead of throwing a nonfatal error? 
There is no data to read so that seems to be the more appropriate course of 
action.

Test script:
---------------
$socket = socket_create(AF_INET, SOCK_STREAM, SOL_TCP);
$connected = socket_connect($socket, '127.0.0.1', 1337); // some server that never sends you data. connection must be accepted though, or else this throws an error.
socket_set_nonblock($socket);
socket_set_option($socket, SOL_SOCKET, SO_RCVTIMEO, array('sec' => 1, 'usec' => 0)); // set timeout to something fast, a second.

while (($read = @socket_read($socket, 1)) === false)
{
	// socket_read throwing an error doesn't mean the connection has failed and the server is gone
	// in context, it just means the server hasn't sent any data yet. [in testing, it never will.]
	if (socket_last_error($socket) != 10035)
		break; // an error that probably means we disconnected has been thrown!
}

echo('yay we did it! '.socket_last_error($socket));

Expected result:
----------------
yay we did it! (some FATAL error code)

Actual result:
--------------
infinite nothingness unless set_time_limit is set, in which case the typical time 
limit exceeded error interrupts the script.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2021-04-06 12:30 UTC] cmb@php.net
-Status: Open +Status: Verified -Type: Bug +Type: Documentation Problem
 [2021-04-06 12:30 UTC] cmb@php.net
> Maybe there's a distinction to be made between fatal and
> nonfatal socket errors.

There is already an distinction: EAGAIN and EWOULDBLOCK are not
reported via the general PHP error handling mechanism.  If you
remove the silence operator from the socket_read() call, there are
no additional warnings for these conditions.  And of course, you
can add special handling for EAGAIN/EWOULDBLOCK (it's a bit
unfortunate that the error numbers are different for Windows and
other systems, but this is not a big deal either).

The timeout also behaves as expected, since recv(2) returns before
the timeout expires.

Note that ext/sockets is a low-level interface to BSD sockets, so
changing this long standing behavior just "because it is
inconvenient" is not an option.  We should, however, improve the
docs to mention this peculiarity.

If anybody feels strongly that the behavior should be changed,
please pursue the RFC process[1].

[1] <https://wiki.php.net/rfc/howto>
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Nov 21 11:01:29 2024 UTC