Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:38898
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.198.229 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:mime-version:content-type;
        b=SC24svyX8QiBYzztcfgzIZL0GWto+pifS4yLMWArIISHQ2LssgWCY4zgOmoBoaYcTd
         3e3uMi3K+wuPfxERs2rheQ3ay0kIlZYEmqESXa0SFcucHBAxfCFffxidFW/j/ZWqayzQ
         ATbvJVe0SsD53DIJ6U6SjYsqWTtZCKmtDvmyU=
Message-ID: <19b0b5c00807100543o50773d26hb7f429e348991191@mail.gmail.com>
Date: Thu, 10 Jul 2008 08:43:54 -0400
To: internals@lists.php.net
MIME-Version: 1.0
Content-Type: multipart/alternative; 
	boundary="----=_Part_11714_12591717.1215693834643"
Subject: persistent sockets need help
From: richard.krehbiel@gmail.com ("Richard Krehbiel")

------=_Part_11714_12591717.1215693834643
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

We are experiencing some problems with persistent sockets (the kind you get
from pfsockopen) and I can't help but conclude that some semantic changes
are needed to make them dependable.  (That is, assuming anyone cares whether
they are dependable.)

The problem is that, in practice, a persistent socket can be handed from one
script to the next in virtually any state.  If one script begins some
transaction on a pfsocket, it's not in an "idle" state that can be handed to
another script until the transaction is completely done.  For example, if
you do an HTTP GET on a pfsocket (assuming Keep-Alive), no other script
should be able to obtain that socket until the reply has been received and
fully consumed by the first script.  But if the first script failed to do
that for any reason, the next script that comes along receives the socket in
a state that it can't use.  It may post it's own HTTP "GET" and then receive
the reply from the last script's uncompleted GET.  And after that, the next
script STILL receives a socket in a bad state, ad infinitum.

..and I'll add that this happens to us on a weekly basis.  Windows Server
2003, IIS 6, PHP 5.2.5, isapi.

If it's possible for a script to detect that it's received a socket in a
non-idle state, it should be allowed to close it (really, truly close it),
at the very least to remove it from the pool of persistent sockets to the
given resource.  But unless I've missed something, it's not possible to
*really* close a pfsocket.  It just gets returned to the resource pool, in
whatever sorry state it's in.

Here's the big part:  I was thinking that a semantic change to persistent
sockets might make it easier for scripts to work "correctly" without
bothering them too much.  The change is this:  If a script doesn't "fclose"
it's "pfsockopen"ed socket, it gets closed *for real* when the script ends.

I suggest this because I think it would make scripts "just work" in the
presence of failures, even if the script coder doesn't completely understand
the principle; it makes the transaction boundaries "automatic".  The down
side is that, if a script forgets the fclose, things work but it doesn't
recycle sockets, it makes new ones all the time.

The other down side is that for old scripts that never had an fclose in
them, they stop getting recycled pfsockets until the fclose is added.

I'm going to do *something* about this myself, anyway.  I'd really like it
if a solution were adopted into the main code base.

------=_Part_11714_12591717.1215693834643--