Olivier,
I've included a TCP modification in the latest patch set that I just sent
to the list.
It corrects three deficiencies:
1. If EAGAIN is returned, then return -1 from the send function so that the
call knows that this message was not sent successfully and will try again.
2. Allow the EAGAIN handling to be performed more than once per execution.
The EAGAIN condition is actually a normal condition on a Unix machine when
there is congestion, so rather than only doing the throttling one time, the
throttling is performed whenever congestion is encountered.
3. Calls where the first message encountered congestion were deleted, but
the statistics did not mark them as failed. Instead of deleting the call,
the patch lets it try again.
I have tested this with the t1 transport option, and it does not noticeably
increase the call rate that I can sustain, but it does reduce the number of
failed calls at higher loads.
Charles
"Olivier Jacques"
<[EMAIL PROTECTED]
com> To
"Bruno, Guerin (NonHP :
10/20/2006 09:58 AtosOrigin)" <[EMAIL PROTECTED]>,
AM Charles P Wright/Watson/[EMAIL
PROTECTED]
cc
sipp-users@lists.sourceforge.net
Subject
Re: [Sipp-users] TCP Error Handling
Questions
Bruno,
thanks for the analysis.
Charles,
as Bruno pointed, we are not very comfortable with the way TCP congestion
is currently implemented. Well, there are several outstanding issues wrt
TCP:
- TCP reads are octet per octet (far from being to say the least!)
- There was a message from Ajay Gupta, back in May 25th. There are 2 fixes
for TCP that looks useful I will integrate that asap.
- Are you looking to work on something else?
Olivier.
On 10/20/06, Bruno, Guerin (NonHP : AtosOrigin) <[EMAIL PROTECTED]>
wrote:
Hello
Concerning TCP congestion, here are some answers:
1) If a message is truncated, the rest of the message (not sent) is sent
as soon as is possible,
i.e. just after a received on the socket and before any other send.
2) The purpose of ctrlEWGlobal is to trace than a problem occurs once
(independantly of
the socket descriptor).
The philosophy behind this is :
-if a problem occurs, a chance is let to solve it.
-if a second problem occurs (even on a different socket), it is because
the system does
not support such traffic, so it is not useful to treat the problem again.
In the implementation, if a first pb occurs, the value of ctrlEWGlobal is
set to true.
If traffic is in mono socket, 'ctrlEW' is set to true.
If traffic is in multi socket a flag, attached to the socket descriptor
(poll_flag_write) is set to true.
No more sent are done till 'ctrlEW' or the flag is set to false.
If a message is received on the socket, it is supposed that the pb is
solve. 'ctrlEW' or the flag is set to false.
SIPp re-starts to send message.
If a new problem occurs (even on a different socket in multi socket
traffic), nothing is done to stop the traffic.
'ctrlEWGlobal' prevents to enable the protection (no send) again.
SIPp continue to trying to send and receive message.
This implementation is probably not the best one.
3) 'ctrlEW' is used in mono socket traffic to trace if a problem (EAGAIN
or EWOULDBLOCK)
occurs during the last send. If a problem occurs 'ctrlEW' is set to
true, no more send are done.
If a message is received, it is supposed that network problems are
solve, so 'ctrlEW' is set to true.
SIPp will try to send message again.
Concerning "incorrect behavior when the TCP window closed and send
returned
EWOULDBLOCK or EAGAIN" problem, no investigation has been done yet.
Regards
Bruno GUERIN
-----Message d'origine-----
De : [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] la part de Charles P
Wright
Envoyé : mardi 17 octobre 2006 23:12
À : sipp-users@lists.sourceforge.net
Objet : [Sipp-users] TCP Error Handling Questions
Hello,
I have a question regarding TCP support under congestion in the latest
SIPp
releases. Previously, there was discussion on the mailing list that
pointed out incorrect behavior when the TCP window closed and send
returned
EWOULDBLOCK or EAGAIN.
I looked at the send_message function, and have the following questions:
1. Why are partial messages treated specially? Why not use the same code
for messages that were not sent at all (an extreme case of being
truncated)?
2. What is the purpose of ctrlEWGlobal? It seems that it causes the code
to be executed only once, because I never see a false value assigned to
it.
3. What is the purpose of ctrlEW?
Thanks,
Charles
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job
easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache
Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job
easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache
Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users
--
HP OpenCall Software
http://www.hp.com/go/opencall/
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users
