Scott, I have no objection to #1, and if Olivier doesn't either, then I think the patch should be applied.
However, for #2 this approach can create problems. The only reason that I have the buffers for partial messages is that we must resend partial messages, otherwise the TCP socket can get corrupted. However, for messages which we did not send at all, we don't need to keep them around; they can just be "lost" like any other UDP packet. If we keep them around, we'll end up with an infinitely growing amount of memory when we start reaching overload. Have you observed a non-blocking write return zero? At least during my testing it would return -1 and then a EWOULDBLOCK (or EAGAIN), which would cause the call to be rescheduled. Of course, if this lasts forever you eventually need to fail the send which is why -send_timeout or timeout="XXX" on a <send> attribute does. Charles [EMAIL PROTECTED] wrote on 10/25/2007 04:48:31 PM: > I'm running sipp on Solaris 10 and am having a couple of issues related > to how it handles socket buffer congestion. > > 1) All writes are done in blocking mode, because in Solaris (if not > other OSes?), MSG_DONTWAIT applies only to recv() calls, not send() > calls. I see in the mail archive that a patch for that was submitted in > January but never made it into the repository (possibly because the > patch was ill-formed, or so it seems to me). > > 2) When a non-blocking write isn't able to write anything (ie, it writes > 0 bytes), the unwritten buffer is never saved anywhere, Hence, when > enter_congestion() returns 0, the unwritten buffer is discarded although > it is counted in the statistics and protocol. It seems that 0 byte > writes should be handled like other partial writes (the buffer saved, > and written when next possble). > > I've attached a patch for these cases. > > -Scott > [attachment "out.diff" deleted by Charles P Wright/Watson/IBM] > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Sipp-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/sipp-users ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Sipp-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sipp-users
