php-java-bridge-users Mailing List for PHP/Java Bridge

Hi,

> even using fflush to try
> and force it to send a packet.)  Jost, do you have some PHP code that
> can reproduce this bug?  


Are you sure. We use fflush() to send out the header immediately so that the back-end can set up the ContextRunner.

I am sure that this worked.


Regards,
Jost Boekemeier



      

Hi,

it is true that PHP buffers data internally. But as soon as read() is called on the same stream, the outgoing data is flushed. The problem is really the "ack delay" caused by BSD's socket implementation.

I suggest to discuss this on the BSD or PHP mailing list, as this affects all PHP applications running on BSD, not only the PHP/Java Bridge.


Regards,
Jost Boekemeier



      

Sorry, seems my attachments were stripped.  Files available at: 
http://vanstaveren.us/~trick/fbsd-nagle-localhost-errorcase/

Cheers,
Patrick


php...@li... wrote:
> [Sorry to  hijack this thread, just replying from a proper email 
> account as my @mintel.com account is using Lotus Notes]
>
> Alright, I've made some good progress here in understanding this bug:
>
> * Grabbed & compiled the test code as on the FreeBSD ML.  Bug 
> reproduced.  Also produced a client fix within the java code using 
> Socket::setTcpNoDelay(true) to bypass Nagle's Algorithm and it proves 
> that this is the socket option that is not being automatically set.
> * Split out the test code into two pieces: a java server which listens 
> for the packet [TestServ.class], java code to act as a client 
> [TestClient.class] and PHP code which does the client end.  I ended up 
> with two PHP implementations in an attempt to reproduce the bug:
> One) which uses fsockopen(...) which is the same socket method that 
> PJB's PHP library uses.  I cannot get this to trigger Nagle's 
> Algorithm.  Inspection using tcpdump shows that the socket created 
> with fsockopen is buffered, so two calls to fwrite (one with a single 
> byte, one with 50 bytes) end up in a single packet as it waits to send 
> data until the socket is closed.  Code attached [fsockopen-client.php]
> Two) which uses the socket_* functions in the PHP Socket extension and 
> a hacky call to socket_set_option to shrink the send buffer size to 1 
> before the first packet ("@") and then expand the buffer size to 51 
> bytes for the second packet.  tcpdump inspection shows that it doesn't 
> produce the exact same size packets as the java code, but it 
> definitely triggers Nagle's Algorithm and the slowdown is roughly the 
> same as the java test client.  Code attached [sockets-client.php]
>
> From there, I sought out to set TCP_NODELAY in PHP:
> * Took a look around the PHP source code in ext/sockets/sockets.c:500+ 
> where the socket options are set.  The PHP constants are [naturally] 
> the same value as whatever the local system has defined for the 
> kernel's integer value of the constant.  TCP_NODELAY on FreeBSD is 
> 0x01.  I added a function call to my sockets-client.php before sending 
> a packet like:
> socket_set_option($sock, SOL_TCP, 0x01, 1); // disable Nagle's Algorithm
> ...and it works like a charm.  Performs like it should.
> * I've patched sockets.c in PHP and recompiled, and now have 
> TCP_NODELAY available in my sockets extension.  Am submitting this 
> patch to PHP for inclusion.  Can now do:
> socket_set_option($sock, SOL_TCP, TCP_NODELAY, 1); // disable Nagle's 
> Algorithm
> ...and again, works like a charm.
>
> Importantly, from the PJB angle: I cannot reproduce the bug with 
> Nagle's Algorithm using the fsockopen socket method (even using fflush 
> to try and force it to send a packet.)  Jost, do you have some PHP 
> code that can reproduce this bug?  I'm really curious.  I'm tempted to 
> say that the buffering used by fsockopen will dodge this bug, but I 
> don't know for sure.  I'm also wondering if the buffering used by 
> fsockopen might actually be incurring an unnecessary (albeit minor) 
> performance penalty on PJB and if the sockets functions might be a 
> wiser choice.  I'm no expert here.
>
> The patch I've written to make TCP_NODELAY available in PHP will fix 
> the bug if we're ever communicating using the sockets extension, but 
> we're using fsockopen.  It's still worth a submit as it might be 
> useful.  I don't know anything about the internals of fsockopen (I'll 
> give the code a read.)  Furthermore there's no method that I can see 
> to set socket options on a stream opened by fsockopen.
>
> Sorry if this is a lot to digest.  Let me know what your thoughts are 
> and most importantly, if you have a way to reproduce this bug using 
> fsockopen in PHP (and thus something that will actually affect PJB.)
>
> Thanks for all your help!
>
> Patrick
>
>
>
>
>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ------------------------------------------------------------------------
>
> _______________________________________________
> php-java-bridge-users mailing list
> php...@li...
> https://lists.sourceforge.net/lists/listinfo/php-java-bridge-users
>   

-- 
Patrick "Trick" van Staveren
http://trick.vanstaveren.us

[Sorry to  hijack this thread, just replying from a proper email account 
as my @mintel.com account is using Lotus Notes]

Alright, I've made some good progress here in understanding this bug:

* Grabbed & compiled the test code as on the FreeBSD ML.  Bug 
reproduced.  Also produced a client fix within the java code using 
Socket::setTcpNoDelay(true) to bypass Nagle's Algorithm and it proves 
that this is the socket option that is not being automatically set.
* Split out the test code into two pieces: a java server which listens 
for the packet [TestServ.class], java code to act as a client 
[TestClient.class] and PHP code which does the client end.  I ended up 
with two PHP implementations in an attempt to reproduce the bug:
One) which uses fsockopen(...) which is the same socket method that 
PJB's PHP library uses.  I cannot get this to trigger Nagle's 
Algorithm.  Inspection using tcpdump shows that the socket created with 
fsockopen is buffered, so two calls to fwrite (one with a single byte, 
one with 50 bytes) end up in a single packet as it waits to send data 
until the socket is closed.  Code attached [fsockopen-client.php]
Two) which uses the socket_* functions in the PHP Socket extension and a 
hacky call to socket_set_option to shrink the send buffer size to 1 
before the first packet ("@") and then expand the buffer size to 51 
bytes for the second packet.  tcpdump inspection shows that it doesn't 
produce the exact same size packets as the java code, but it definitely 
triggers Nagle's Algorithm and the slowdown is roughly the same as the 
java test client.  Code attached [sockets-client.php]

 From there, I sought out to set TCP_NODELAY in PHP:
* Took a look around the PHP source code in ext/sockets/sockets.c:500+ 
where the socket options are set.  The PHP constants are [naturally] the 
same value as whatever the local system has defined for the kernel's 
integer value of the constant.  TCP_NODELAY on FreeBSD is 0x01.  I added 
a function call to my sockets-client.php before sending a packet like:
socket_set_option($sock, SOL_TCP, 0x01, 1); // disable Nagle's Algorithm
...and it works like a charm.  Performs like it should.
* I've patched sockets.c in PHP and recompiled, and now have TCP_NODELAY 
available in my sockets extension.  Am submitting this patch to PHP for 
inclusion.  Can now do:
socket_set_option($sock, SOL_TCP, TCP_NODELAY, 1); // disable Nagle's 
Algorithm
...and again, works like a charm.

Importantly, from the PJB angle: I cannot reproduce the bug with Nagle's 
Algorithm using the fsockopen socket method (even using fflush to try 
and force it to send a packet.)  Jost, do you have some PHP code that 
can reproduce this bug?  I'm really curious.  I'm tempted to say that 
the buffering used by fsockopen will dodge this bug, but I don't know 
for sure.  I'm also wondering if the buffering used by fsockopen might 
actually be incurring an unnecessary (albeit minor) performance penalty 
on PJB and if the sockets functions might be a wiser choice.  I'm no 
expert here.

The patch I've written to make TCP_NODELAY available in PHP will fix the 
bug if we're ever communicating using the sockets extension, but we're 
using fsockopen.  It's still worth a submit as it might be useful.  I 
don't know anything about the internals of fsockopen (I'll give the code 
a read.)  Furthermore there's no method that I can see to set socket 
options on a stream opened by fsockopen.

Sorry if this is a lot to digest.  Let me know what your thoughts are 
and most importantly, if you have a way to reproduce this bug using 
fsockopen in PHP (and thus something that will actually affect PJB.)

Thanks for all your help!

Patrick





-- 
Patrick "Trick" van Staveren
http://trick.vanstaveren.us