Posted by "Geoff" on 01/20/06 02:49

Richard, have you seen this:
http://bugs.php.net/bug.php?id=5153&edit=1
This bug goes back to June 2000. And it's closed even though it is
clearly not fixed. Doesn't seem like they'll get to it anytime soon.
You might have to do it the long way, building your own protocol
handlers. Or, you might want to look into a 3rd party library, or a
command line option like "lynx -dump -connect_timeout=n <uri>" which
is multi-resource aware.

Geoff.


On 19 Jan 2006 at 17:28, Richard Lynch wrote:

> 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
>
>
>
>
> !DSPAM:43d02ead91711894325842!
>

[Back to original message]