#32979 [Opn-Asn]: socket stream opened with stream_socket_client doesnt work with stream_select

2006-01-17 Thread sniper
 ID:   32979
 Updated by:   [EMAIL PROTECTED]
 Reported By:  mjpph at stardust dot fi
-Status:   Open
+Status:   Assigned
 Bug Type: Network related
 Operating System: Linux (Fedora Core 3)
-PHP Version:  5CVS-2005-05-08 (dev)
+PHP Version:  5CVS-2006-01-18 (dev)
 Assigned To:  wez


Previous Comments:


[2006-01-17 23:08:59] mjpph at stardust dot fi

Doesn't work with the php5.1-200601172130.tar.gz snapshot nor with
5.1.2.



[2005-11-07 00:08:49] [EMAIL PROTECTED]

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





[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



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 [Opn-Asn]: socket stream opened with stream_socket_client doesnt work with stream_select

2005-05-30 Thread sniper
 ID:   32979
 Updated by:   [EMAIL PROTECTED]
 Reported By:  mjpph at stardust dot fi
-Status:   Open
+Status:   Assigned
 Bug Type: Network related
 Operating System: Linux (Fedora Core 3)
 PHP Version:  5CVS-2005-05-08 (dev)
 Assigned To:  wez


Previous Comments:


[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.



[2005-05-30 16:33:24] [EMAIL PROTECTED]

Can you now check it with valgrind, please?




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 [Opn-Asn]: socket stream opened with stream_socket_client doesnt work with stream_select

2005-05-27 Thread sniper
 ID:   32979
 Updated by:   [EMAIL PROTECTED]
 Reported By:  mjpph at stardust dot fi
-Status:   Open
+Status:   Assigned
 Bug Type: Network related
 Operating System: Linux (Fedora Core 3)
 PHP Version:  5CVS-2005-05-08 (dev)
 Assigned To:  wez


Previous Comments:


[2005-05-26 19:18:35] mjpph at stardust dot fi

Yes it works with FC2 but not with FC3, but I have tested it with
several kernels the only thing that matches is Fedora Core version.
Also socket_select and stream_select works perfectly well with other
streams/sockets, only exceptions are streams returned by
stream_socket_client() or stream_socket_server().



[2005-05-26 18:54:13] [EMAIL PROTECTED]

So, PHP works fine on FC2, and the same version of PHP doesn't work on
FC3?
Sounds like you have a problem with your kernel; if so, this isn't a
php bug.



[2005-05-26 17:50:51] mjpph at stardust dot fi

Another update. I modified the test script to connect to HTTP which
doesn't output anything directly but instead waits for request from the
client. In this case the select timeouts on FC3 like it should, but
obviously doesn't return anything either as the connection doesn't
output anything. When the HTTP closes the connection the stream_select
starts behaving like with the SMTP example, looping as fast as it can.
If I change the port to SMTP with instant output, it loops the
stream_select() like a madman without the requested 5 second delay.

The working (FC2) script:
select(4, [3], [], [], {0, 5000})   = 0 (Timeout)
select(4, [3], [], [], {0, 5000})   = 1 (in [3], left {0, 4000})
select(4, [3], NULL, NULL, {60, 0}) = 1 (in [3], left {60, 0})

First it selects and timeouts when waiting for data, then it returns 1
for changed streams and the stream resource (3) as the changed stream.
So this works as expected.

Here, the non-working FC3 version:
select(4, [3], [], [], {5, 5000})   = 1 (in [3], left {4, 998000})
select(4, [3], [], [], {5, 5000})   = 1 (in [3], left {5, 5000})
select(4, [3], [], [], {5, 5000})   = 1 (in [3], left {5, 5000})

It returns the same as the FC2 (except the one with the nulls) so this
should indicate AND return PHP's stream_select() with the value of 1,
but by checking the PHP's stream_select() return value it's always 0.
It's like the system level select() works ok but the PHP function fails
to return it's results correctly? Also something that bothers with me
this conclusion is that there's not a single timeout in the FC3 case
which could indicate some other problem as well, maybe the connection
isn't established correctly?



[2005-05-26 17:38:20] mjpph at stardust dot fi

I also noticed something funny now. If I use 5 second delay on the
stream_select and watch strace directly it doesn't wait at all, it just
loops stream_select() as fast as it can. Also there's no timeout on the
FC3 straces, but there is one timeout before the successful select on
FC2 strace. One can conclude that the SMTP server responds with 5ms+
delay causing stream_select to timeout once before it gets input. It's
like the FC3 script returns from the stream_select() for some reason
with instant timeout and not actually doing the actual select at all.



[2005-05-26 17:30:16] mjpph at stardust dot fi

Also PHP 5.1.0-dev (cli) (built: May 21 2005 21:29:39)
works fine under FC2. It seems this is PHPFC3 issue.

Here's strace from the working (FC2) script:
connect(3, {sa_family=AF_INET, sin_port=htons(25),
sin_addr=inet_addr(HIDDEN)}, 16) = -1 EINPROGRESS (Operation now in
progress)
select(4, [3], [3], [3], {60, 0})   = 1 (out [3], left {60, 0})
getsockopt(3, SOL_SOCKET, SO_ERROR, [17179869184], [4]) = 0
fcntl(3, F_SETFL, O_RDWR)   = 0
select(4, [3], [], [], {0, 5000})   = 0 (Timeout)
select(4, [3], [], [], {0, 5000})   = 1 (in [3], left {0, 4000})

Here's strace from the non-working version (FC3)

connect(3, {sa_family=AF_INET, sin_port=htons(25),
sin_addr=inet_addr(HIDDEN)}, 16) = -1 EINPROGRESS (Operation
poll([{fd=3, events=POLLIN|POLLOUT|POLLERR|POLLHUP, revents=POLLOUT}],
1, 6) = 1
getsockopt(3, SOL_SOCKET, SO_ERROR, \0\0\0\0, [12884901892]) = 0
fcntl(3, F_SETFL, O_RDWR)   = 0
select(4, [3], [], [], {0, 5000})   = 1 (in [3], left {0, 0})
select(4, [3], [], [], {0, 5000})   = 1 (in [3], left {0, 5000})
select(4, [3], [], [], {0, 5000})   = 1 (in [3], left {0, 5000})
select(4, [3], [], [], {0, 5000})   = 1 (in [3], left {0, 5000})

.. to the infinity.



The remainder of the comments for this 

#32979 [Opn-Asn]: socket stream opened with stream_socket_client doesnt work with stream_select

2005-05-25 Thread sniper
 ID:   32979
 Updated by:   [EMAIL PROTECTED]
 Reported By:  mjpph at stardust dot fi
-Status:   Open
+Status:   Assigned
 Bug Type: Network related
 Operating System: Linux (Fedora Core 3)
 PHP Version:  5CVS-2005-05-08 (dev)
-Assigned To:  
+Assigned To:  wez


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