On Thu, 2010-12-02 at 07:29 +0800, Joegen Baclor wrote: > I briefly looked at the code and the likelihood of a hog getting into a > frenzy is this place (see snippet below). > > 1. If the readBuffer is non-null after the last read iteration, then it > is residual. This can happen if the sip packet has extra bytes > overruning the actual content length it announced. This will be > consumed by the next read interation. > > 2. If there is always available new data prior to call to poll, then > poll would return right away and call POLLIN. > > One can easily, intentionally, reproduce this by opening a TCP socket to > port 5060 and send it garbage in a perpetual loop and get the hog in frenzy. > > I tryed this but seems that is not the case.
I guess the problem rely on something strange into the network. I can just say that when a socket has trouble, the poll request return revent=0x1d and in this case control loop screw up 'cause of the POLLHUP&&POLLERR case never run. Speculating on this I suspect that the perfect solution would be remove all "else" and check all events (POLLIN,POLLOUT,POLLHUP,POLLERR) for each loop, but the patch i've sent seems work very well. thanks Domenico Chierico _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev/
