> 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.
It doesn't make sense to me that the TCP side would intentionally lose
data. I understand that the protocol needs to deal with UDP and lost
packets, but one of the primary reasons for selecting TCP is so that
data won't be lost.
In the case of saving a particular message on a 0-byte write, it's only
a few bytes more than saving a partial message. Or is it the case that
several messages would get saved to pending messages in that case (as
opposed to really only one partially-written message)? I see where that
could cause a potential issue, but I still don't think that dropping the
TCP data is the right thing to do.
> 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.
I said it returns 0, but I meant that it returns -1/EAGAIN (too long
since I've looked at C/C++ code :-). But the program logic in either
case (a return of <=0) is the same in the existing code, and in the
existing code, it doesn't reschedule the call -- it just drops that data
request, and the call eventually fails/times out. Which is what you
implied you expected in the previous paragraph, so I'm confused whether
you think this is working correctly or not.
It occurred to me that the intent might be to reschedule sending the
data, because the send_message() return call is propagated up the stack,
and the call::run() method says:
if(send_status == -1) { /* Would Block on TCP */
But the send_status is 0 when TCP blocked (it comes ultimately from
enter_congestion(), which always returns 0). But I'm also not sure that
returning the correct status (-1) would actually reschedule the call; I
went down that path, and it didn't seem to work (the message is still
never resent), and then it occurred to me that simply queuing the unsent
message as if it were a partial message would accomplish the same goal.
-Scott
-------------------------------------------------------------------------
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
