[2nd try] PHP client question: why socket_create()?
Ryan T. Dean
Mon, 6 Oct 2003 16:46:09 -0400
Content-Type: text/plain; charset=us-ascii
On Mon, Oct 06, 2003 at 10:39:47AM -0400, Justin Matlock wrote:
> Because when the first client was written, streams didn't work properly, =
> I think Ryan (the original author) was just trying to get a version out t=
> worked, and not deal with the funky PHP bugs that existed then...
I guess I'm a little confused. I've got code written for 4.1 that uses=20
fsockopen(). Granted the newer stream_* functions came with 4.3.0, but=20
you could still control blocking and everything via the=20
socket_set_blocking, socket_set_timeout and socket_get_status (which are=20
now just wrappers for the new stream_* functions).
In any case, I received a request to 'update' the PHP client. While I =20
had been planning on writing my own client anyway sometime next week for=20
inclusion in a project of my own, the request stated that a number of =20
people are having problems with the current client, so instead I stayed=20
up all night last night reporting the Perl client to PHP.
The port is a direct port, because I wanted to get it done. Ever have =20
something just grab onto you and you couldn't stop thinking about it? =20
This happened to me last night. =20
In any case, I'm using (p)fsockopen - my implementation works on 4.3.3 =20
and 4.3.4.rc1. To use the persistant version, when initializing the =20
object add a 'persistant' key to the args array with a value of true.
My only outstanding bug is in run_command - which the current PHP client=20
doesn't even support. run_command is supposed to return an array of=20
strings, each string being a single line as read from the server. =20
Strangely, fgets() (at least on FreeBSD) modifies the linebreak from=20
\r\n to just \n. fread() doesn't have this broken behaviour, but the=20
resulting logic to turn fread() data into an array of strings gets a=20
little ugly when you have to cosider that you may have stopped a read=20
mid-string. Alternatively, each line after its read I could check to=20
to see if \r\n is present at the end of the line, and if not, to rtrim()=20
the current line and append a \r\n. Each has its merits - but=20
run_command does work now, if your program doesn't have a dependancy on=20
the \r\n at the end of every string in the array.
I suspect the client may be a little slow retrieving keys yet; using get=20
on a valid key with 36 bytes of data takes around 0.095 seconds on my=20
test box (a 380mhz amd k62 with 192mb of memory). get_multi on three=20
keys (said 36 byte block plus two different values I've been=20
incr/decring) takes around 0.103 seconds. This may be normal delay;=20
I'll have to go through and profile _load_items and see where the delay=20
Please note that this is a direct, get-it-done port. It doesn't yet =20
take advantage of PEAR's error handling yet. It will eventually. Right=20
now, false and null indicate failure, while true and/or a value indicate=20
success - just like the Perl client. =20
All this having been said, the client is currently available at=20
I would appreciate any help in testing it. If you can break it, I'd=20
like to know how; if its slow doing something, tell me what you are=20
trying to do.
-Ryan T. Dean
PS- As a side note, the original reasoning behind writing my own client=20
was for my new module framework which I've been developing/using for my=20
own PHP projects, which are mainly content management systems. I was =20
also planning on working it into Cache in PEAR.
PPS- Testing on 4.3.4.rc1 was done using my very basic testsuite which=20
hits all the big functionality: add, replace, set, get, get_multi, incr,=20
decr, delete. Testing is done with small, medium, and large sized data=20
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)
-----END PGP SIGNATURE-----