Re: Sockets Timeout Problem

OK, I agree in principle. But is 10 seconds a "good" default? Would 60 seconds be "better" in that it allows a more realistic length of time for data to flow by default, but still has a cutoff point? (I'm thinking of not-so-fast connections; our ISDN link can sometimes stall for a relatively long time while transitioning from 2 channels down to 1; 10 seconds would be too short for us in that case). If people need shorter timeouts, they can use the socket_set_timeout function to alter it; I don't think they should have to set a longer timeout in their scripts because the default is too short for most users. Is there a better way of deciding just what length to use? It's all pretty arbitrary :-) Perhaps this is a case where a configuration directive is useful (such as streams.default_timeout), I'm copying this to php-dev to get some more opinions on the matter. For the sake of the people on php-dev, the proposed solution is to change the default timeout for socket streams to be X seconds, where X is an abitrary length of time that needs to be long enough for most users that they don't notice this change, but short enough that a DOS attack is not so deadly. The modification would be made to main/network.c, line 511. --Wez. On 08/05/02, "Ilia A." <ilia@prohost.org> wrote: > There is a problem with PHP in the way it currently handles opening of > connections to remote servers via php_streams. The problem can cause a PHP > script to sit a virtually forever inside a select() waiting for a response > from a remote server. This in turn causes an a webserver child, to become > effectively dead and if it happens enough times cause a denial of service.