#32979 [Asn-Fbk]: socket stream opened with stream_socket_client doesnt work with stream_select
ID: 32979 Updated by: [EMAIL PROTECTED] Reported By: mjpph at stardust dot fi -Status: Assigned +Status: Feedback Bug Type: Network related Operating System: Linux (Fedora Core 3) PHP Version: 5CVS-2005-05-08 (dev) Assigned To: wez New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip Previous Comments: [2005-07-28 01:50:49] lew at mailduct dot com wez -- the problems reported here are all due to a previously fixed bug which has crept back into PHP. It has to do with how the PHP library treats EOF under FreeBSD vs Linux. You worked on this problem previously... please take a look at the currently active Bug #32858 reported by me, as well as your prior fix in Bug #25649. Thanks Lew Payne [2005-05-30 22:11:28] mjpph at stardust dot fi I haven't had problems with different kernels. Only the combination of x86_64, stream_socket_client() or stream_socket_server(), stream_select() and PHP OpenSSL-support seem to reproduce this every time. [2005-05-30 21:57:34] fox dot 69 at gmx dot net i experience a similar problem since the latest standard kernel update with yum (host.domain.com point to the main server IP) : ? $url=http://host.domain.com;; $fp = fopen ($url,r); $buffer=fread($fp,8192); fclose($fp); echo $buffer; ? booted with kernel-2.6.11-1.14_FC3 package: OK booted with kernel-2.6.11-1.27_FC3 package: NOT OK (timeout) NOTE: but only if host.domain.com point to the executing host itself - same with localhost - for all others it seem to be fine [2005-05-30 16:58:42] mjpph at stardust dot fi Also trying to compile valgrind on x86_64 results in: checking for a supported CPU... no (x86_64) configure: error: Unsupported host architecture. Sorry [2005-05-30 16:56:03] mjpph at stardust dot fi I could, but I get this: valgrind: Can only handle 32-bit executables On a 32bit executable and with openssl stream_select() worked ok. On a 64bit PHP executable it doesn't. 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/32979 -- Edit this bug report at http://bugs.php.net/?id=32979edit=1
#32979 [Asn-Fbk]: socket stream opened with stream_socket_client doesnt work with stream_select
ID: 32979 Updated by: [EMAIL PROTECTED] Reported By: mjpph at stardust dot fi -Status: Assigned +Status: Feedback Bug Type: Network related Operating System: Linux (Fedora Core 3) PHP Version: 5CVS-2005-05-08 (dev) Assigned To: wez New Comment: *please* paste the exact script you are using that produced those straces. Previous Comments: [2005-05-27 15:21:54] [EMAIL PROTECTED] Whenever I see FC3-specific problems I always suspect SELinux. Although I don't see how that can affect a select() [2005-05-27 14:14:29] mjpph at stardust dot fi Also, I run constantly a lot more complex PHP-scripts on both FC2 and FC3 servers, on different kernels and by using normal socket and stream functions. They all function perfectly well. All this seems to point to the new stream_socket functions as stream_select works with all the other streams except the ones opened with stream_socket functions. [2005-05-27 14:10:52] mjpph at stardust dot fi Only change has been the service port and sometimes the IP if the actual server doesn't host it's own SMTP. I've tested the SMTP availability with telnet and by using fgets instead of stream_select. So yes, the test code fails on FC3 and works on FC2 when the actual ip:port is changed to point to an available SMTP service. [2005-05-27 14:06:00] [EMAIL PROTECTED] Have you pasted the script that you're actually running with those straces? Are you really using the one from your initial post? [2005-05-27 09:59:17] mjpph at stardust dot fi Also, all the kernels I've used are different versions of FC3 stock kernels without modifications. As FC3 is quite popular Linux I'd assume that many people will have problems with the new functions when they adopt them. Of course it can be a kernel problem, but it can also be a PHP problem which only exhibits on FC3 or with certain kernel settings, but that's more your field to conclude than mine :) 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/32979 -- Edit this bug report at http://bugs.php.net/?id=32979edit=1
#32979 [Asn-Fbk]: socket stream opened with stream_socket_client doesnt work with stream_select
ID: 32979 Updated by: [EMAIL PROTECTED] Reported By: mjpph at stardust dot fi -Status: Assigned +Status: Feedback Bug Type: Network related Operating System: Linux (Fedora Core 3) PHP Version: 5CVS-2005-05-08 (dev) Assigned To: wez New Comment: Worked for me just the other week. You'll need to convince me with a short self-contained test and strace output to prove it. Previous Comments: [2005-05-09 09:51:34] mjpph at stardust dot fi No I used http only as an examply not thinking that it doesn't actually output anything straight away. I used the example code on several services that output information straight from connect without needing any input from the client. For example port 25 welcome message and several others. Telnet straight away you get a welcome. Use only fgets, you get a welcome. Use the example code, you get nothing. Didn't try anything which actually closes the connection after the output, as this isn't the case with my own implementation either and shouldn't be a requirement anyway. The case is always the same, fgets would get input straight away but stream_select stays dead no matter how many times it loops and waits. Setting the stream to blocking or non-blocking mode has no effect on stream_select's behaviour on this case. The data in the buffer just stays there and stream_select is completely ignorant about it. So, the read wouldn't block (as I know there is data pending), but even despite that stream_select returns 0 changed streams always. So it thinks that read would block, in reality, it doesn't. Partly unrelated: I have this code in a script which also selects stdin. The stdin select works as expected, the stream_socket selecting select doesn't. I had a perfectly working implementation with socket-based functions which stalled at the selects right after I changed to stream_socket-based functions. [2005-05-09 01:26:32] [EMAIL PROTECTED] Is the server end of the socket talking http? If not, does it send data to the client immediately upon client connection (without expecting data from the client first)? If not, stream_select() is working precisely as it should. Also note that stream_select() tells you only if a read or write would not block, not whether there actually is data pending. [2005-05-08 23:06:40] mjpph at stardust dot fi The issue is the same when using stream_socket_server. stream_socket_accept works as expected, but if you select the socket it always returns 0, even if there is a pending connection which would be returned with stream_socket_accept. [2005-05-08 22:50:58] mjpph at stardust dot fi Correction to the previous comment. The fread has to be done before every stream_select to obtain any other value from stream_select other than 0. stream_get_meta_data also reports pending data as 0 before the fread and non-zero value right after the 1 byte fread. [2005-05-08 22:46:55] mjpph at stardust dot fi Also, adding fread($c,1); after stream_socket_client and before the while loop enables correct functionality of the stream_select function from that pont on. 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/32979 -- Edit this bug report at http://bugs.php.net/?id=32979edit=1
