On Thu, January 19, 2006 4:08 pm, Geoff wrote:
> I honestly have no idea if this would work, but maybe fopen supports
> non-blocking connections?
Not as far as I can tell...
You can call stream_set_blocking after it's open, but that doesn't
help a slow connection in the first place.
> Or creation of context-based connections
> (for which you can use stream_set_blocking).
Unless I'm seriously mis-reading docs, stream_set_blocking can only be
called on an already-open stream, not on the soon-to-be-opened stream.
fopen() in PHP5 does take a context, and if I could figure out how to
embed the concepts of "do not block" and "timeout in $x seconds"
within a context from the docs, and if fopen() would still handle all
the details of the various protocols, I'd be all set...
That's sort of what I was asking for in the original email, but...
It seems like you have to specify the 'scheme' as the key in the
context array.
So, I guess, I could, in theory, find a listing of all the schemes
fopen() supports, which might even be in a function, iterate over all
of those, and do something like:
$schemes = function_that_returns_all_schemes_fopen_supports();
$opts = array();
foreach($schemes as $scheme){
$opts[$scheme]['some_magic_undocumented_thing'] =
STREAM_CLIENT_ASYNC_CONNECT | STREAM_CLIENT_CONNECT ;
}
$foo = fopen($url, 'r', false, $opts);
if ($foo == false) $errors[] = "$url timed out";
Only problem is, these constants are documented ONLY to work with:
http://www.php.net/manual/en/function.stream-socket-client.php
and that pretty clearly is working at a much lower-level than fopen
(and friends) as the very first example shows using TCP as a protocol,
and then you have to send the GET and any other headers, which is
exactly what I'm trying to avoid having to re-code in the first place.
So I'm back to square one, as far as I can see from the docs...
It's possible (still) that I'm just mis-reading docs, or am
continually skipping over the one new page in 'streams' that is making
everybody think this should be so simple, but I don't think so, since
I've read EVERY page in the new streams section several times now.
I'm not claiming 100% comprehension of every implication on every
page, mind you :-)
> If so, you could take a
> stamp of the current time plus a timeout value, make the fopen call
> (which would return immediately) then wait politely (I mean that
> from a CPU perspective) in a loop until you have data, or the
> current time goes past your time stamp.
Yes -- if I could compose a stream_context doohickey that convinced
fopen() to use a time-out...
> Another avenue for investigation might be to try file_get_contents
> to see if it's connection timeout can be controlled. It seems to
> work in a similar way to fopen, in terms of having wrappers that are
> aware of multiple resource types.
file_get_contents() seems to suffer from the exact same limitations of
file()
I get the simplicity of fopen() with no control over connection timeout.
Maybe there is some underlying voodoo going on in the PHP internals
that some makes it crystal-clear why that has to be, but to this naive
user, if fsockopen can have a timeout, fopen and friends out to be
able to also, at least for schemes that support such a thing.
Obviously SOME kind of timeout is involved somewhere in fopen()
because it WILL timeout on some sites sometimes, even though
experimentation has shown that had it waited, it would have gotten
data eventually.
> It might also be worth taking a look at cURL or similar libraries
> that are also multi-resource aware, but give you greater control of
> connections parameters and timeouts.
Maybe I've been mis-using cURL all these years, but it doesn't seem to
be anywhere near as simple as the mythical function I've described,
and really not much better than a giant switch for fsockopen to
duplicate all that code that's gotta be down in the guts of fopen (and
friends)
--
Like Music?
http://l-i-e.com/artists.htm
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
