PEAR Bug Search Results

Net_Socket: Bug 26998 [Open] Endless loop in write() if connection broken

borz_off at cs dot msu dot su — 2020-11-11T19:26:09+00:00

Net_Socket Bug
Reported by avb
2020-11-11T19:26:09+00:00
PHP: Irrelevant OS: Windows Package Version: 1.2.2

Description:
------------
write() function has a separate code path for OS_WINDOWS containing a while ($pos < $size) loop. Value returned by fwrite() call within a loop is checked for errors with === false.

Unfortunately, as this comment in PHP manual states
http://www.php.net/manual/en/function.fwrite.php#96951
fwrite() almost never returns false, it returns 0 in case of errors like broken connection. So the loop never exits.

The problem was re-introduced by https://github.com/pear/Net_Socket/pull/3 most likely as this was fixed a waaaaay back in https://pear.php.net/bugs/bug.php?id=14619

Test script:
---------------
require_once 'Net/Socket.php';

set_error_handler(
    function ($errNo, $errStr) {
        echo $errStr . ' [code: ' . $errNo . "]\r\n";
    },
    E_ALL & ~E_STRICT & ~E_DEPRECATED
);

$suckIt = new Net_Socket();
$suckIt->connect('tcp://localhost', 80);
stream_socket_shutdown($suckIt->fp, STREAM_SHUT_WR);
echo $suckIt->write("ANYTHING");


Expected result:
----------------
One error saying "write failed" or something

Actual result:
--------------
Endless barrage of
fwrite(): send of 8 bytes failed with errno=10058 A request to send or receive data was disallowed because the socket had already been shut down in that direction with a previous shutdown call.
 [code: 8]

Net_Socket: Bug 23768 [Open] Git tag of v1.2.2 is incorrect

legoktm at member dot fsf dot org — 2018-09-13T20:12:06+00:00

Net_Socket Bug
Reported by legoktm
2018-09-13T20:12:06+00:00
PHP: 5.6.38 OS: Fedora Package Version: 1.2.2

Description:
------------
The v1.2.2 git tag is incorrect, it points to a commit from 2015: . This means that anyone using composer is getting the wrong version of the package.

Test script:
---------------
Run composer install pear/net_socket

Expected result:
----------------
I expect that 7482c62deab2c2685e00c221d97a83e17c795ef8 is installed.

Actual result:
--------------
bbe6a12bb4f7059dba161f6ddd43f369c0ec8d09 is actually installed, which  is from 2015.

Net_Socket: Bug 18176 [Assigned] socket behavior dependent on the order that sockets are disconnected

cstanley at cstanley dot no-ip dot biz — 2017-04-11T19:00:25+00:00

Net_Socket Bug
Reported by claytontstanley
2011-01-06T21:59:28+00:00
PHP: 5.3.3 OS: Suse Linux (32-bit) Package Version: 1.0.10

Description:
------------
In the same php process, suppose I connect to a socket 
server on port A, and then init another object and connect to a 
server on port B.

If I close the socket on port B before port A, I get this netstat 
behavior for port A during the run:


tcp        0      0 localhost:9099          localhost:58275         
ESTABLISHED 
tcp        0      0 localhost:58275         localhost:9099          
ESTABLISHED 

tcp        0      0 localhost:9099          localhost:58275         
CLOSE_WAIT  
tcp        0      0 localhost:58275         localhost:9099          
FIN_WAIT2   

tcp        0      0 localhost:58275         localhost:9099          
TIME_WAIT   


But if I close the socket on port A before B, I get this netstat 
behavior for port A during the run:

tcp        0      0 localhost:43684         localhost:9559          
ESTABLISHED 
tcp        0      0 localhost:9559          localhost:43684         
ESTABLISHED

tcp        0      0 localhost:9099          localhost:49145         
FIN_WAIT2   
tcp        1      0 localhost:49145         localhost:9099          
CLOSE_WAIT  

tcp        0      0 localhost:9099          localhost:49145         
TIME_WAIT   

Note how things are flipped with these cases. I am not sure if 
this is an issue with net_socket, but I'm hoping that you all can 
help me figure out the solution, 
as the problem does present itself when using the net_socket 
package.

The reason why this is an issue is b/c the 2nd scenario causes 
the system to be in a TIME_WAIT state on port A after closing 
the php process, and the 1st 
scenario doesn't. Being in a TIME_WAIT state means that a 
socket server cannot bind to that port (that is, unless the 
server has the reuse address flag set 
to true), so scenario 2 has to wait a few minutes for the 
TIME_WAIT to disappear while scenario 1 doesn't. All of this 
b/c I changed the order in which the 
sockets were disconnected. If each of these connections are 
independent (which, at first pass, I would think that they are), 
why would there be an order 
dependence on when they are destructed?

Also, this happens for N socket connections on a single 
process. The only way to keep the TIME_WAIT state from 
happening is to close the sockets in the 
reverse order they were constructed.

Thanks very much for any help/info you are willing to give for 
this issue,
-Clayton