Hi
All,
Following
up the invalid handle issue in my last post, I was trying to isolate the
problem by solely using the reSIProcate’s own code.
I
was using SIPP to test against a UAS that is based on DUM’s pager message
classes. I have got a ServerMessageHandler class derived from ServerPagerMesssageHandler, in which the onMessageArrived() function was overridden
like this(standard routine implementation):
virtual
void onMessageArrived(ServerPagerMessageHandle handle, const SipMessage&
message)
{
SharedPtr<SipMessage> ok =
handle->accept(200);
handle->send(ok);
Contents *body = message.getContents();
if(body->getType().type() ==
"text/plain")
{
cout << "Message
RECEIVED: " << *body <<
"\n";
}
}
I
was trying to find out how this piece of code that is using only the DUM code
performs to generate the “200 OK” response.
The
test got started at a rate of 1 message per second(mps) under Wireshar’s
monitoring, and the rate was gradually increased. At the rate of 6-7 mps,
everything is fine, except that it looks like the DUM begins to fail to keep up
with the message sending rate, according to Wireshark. At the rate of about 30
mps, the retransmission begins to appear and it is more significant that the
DUM cannot keep up with the request message, but the “200 OK” responses are
always received, according to the SIPP statistics. At the rate of 35 mps,
timeout begins to appear, together with SIPP’s failing to receive the “200 OK”
response.
I
am not 100% sure if I have written the UAS correctly, but the test kinda shows
that the DUM is much slower or more error-prone than the reSIProcate SIP stack
itself, as there are many posts online shows that the SIP stack is able to
handle thousands of sip messages per second, given that the pager message is
just one simple sip message. Also, does the timeout have something to do with
the invalid handle issue that I mentioned in my last post? Or has anybody come
across the invalid handle issue while queueing DUM commands under high
messaging rate to share some possible solutions? Thanks very much.
Regards,
Alex
----- 转发的邮件 -----
发件人： he yaxin <crazyplayer1983@xxxxxxxxxxxx>
收件人： "resiprocate-users@xxxxxxxxxxxxxxx" <resiprocate-users@xxxxxxxxxxxxxxx>
发送日期：
2011年12月7日, 星期三, 下午 3:22
主题: invalid handle while queueing DUM commands
Hi all,
I am using the solution of queueing DUM commands
to call DUM APIs from different threads.
While I was load testing my application, I
accidentally found that mHandle.isValid() returned false. And it returned false significantly
frequently if the call rate was higher than 3 calls/second. (PS. There is no problem when the call rate was 1 call/second.)
I have a ServerPagerMessageCompletionCommand class that looks like this
class
ServerPagerMessageCompletionCommand : public DumCommand
{
public:
ServerPagerMessageCompletionCommand(ServerPagerMessageHandle
h, int code) : mHandle(h), mResponseCode(code) {}
void executeCommand()
{
if(mHandle.isValid())
mHandle->send(mHandle->accept(mResponseCode));
}
private:
ServerPagerMessageHandle
mHandle;
int mResponseCode;
}
The ServerPagerMessageCompletionCommand gets constructed when it is ready to send back
a response. The previously stored ServerPagerMessageHandleand response code from the non-SIP server will
be passed to its constructor. Since the ServerPagerMessageHandle is getting corrupted when the call rate is
high, there is no way to send back a response to the originating SIP entity,
causing abnormal behaviors in the SIP domain.
My application is primarily about messaging and
it is expected the message traffic could be massive, so it is vital for me that
every message dialogue is handled properly. Does anyone have a clue on this?
How can the mHandle be invalid? Or am I missing something in
queueing DUM commands? Thanks very much!
Regrads,
Alex