[Asterisk-code-review] SIP: Rewrite tcpauthlimit test in Python (testsuite[master])

[Ashley Sanders]

Ashley Sanders has posted comments on this change.

Change subject: SIP: Rewrite tcpauthlimit test in Python
......................................................................


Patch Set 6:

(1 comment)

https://gerrit.asterisk.org/#/c/1055/6/tests/channels/SIP/tcpauthlimit/tcp_scenario.py
File tests/channels/SIP/tcpauthlimit/tcp_scenario.py:

Line 181:             return (
        :                 ConnectionState.DONE if se.args[0] == EWOULDBLOCK
        :                 else ConnectionState.LOST)
> I'm not sure I understand the logic here, so a comment would be helpful. Sp
First, allow me to state that this is never how I would write a client that was not part of a test of some kind. This is a terrible abuse of the rules of TCP. 

Here, the twisted.internet.tcp.EWOULDBLOCK is error code 11, or Resource Not Available. Ordinarily, the way things work in Twisted is that if that code is received while reading/writing from/to the socket, the error is swallowed up (if the timeout has not yet occurred) and the client still believes there is a connection, which is correct.

Here, though, I _know_ that this is the state I will end up in when Asterisk kills an unauth attempt. Asterisk gets the request for the socket and when it determines the number of unauth'd sockets exceeds the limit, it just closes the fd. The client doesn't get a message, but from Asterisk's perspective, why should it bother sending a message? It was an unauth'd connection attempt, anyway.

So, the goal of this test is to iterate over 150 messages, and for each multiple of 10, try to read from the socket. This should give the Asterisk side ample time to compose a response (especially considering it only has to go as far as the loopback address). If we don't have a response by the 151st message, then it is probably safe to assume that the Asterisk side dropped the connection. This obviously is not a fool-proof method of determining if the host is truly gone; however, the only fool-proof methods would be to either let the TCP connection actually timeout, which is going to kill the reactor (and Jenkins probably), or modify Asterisk to send a full shutdown to the client.

ConnectionState.DONE is a local class and is only used for my purposes here, which is to override the default behavior of the Twisted Protocol and ClientProtocolFactory. 

The fact that I am calling this state DONE - "Hey, this resource is still unavailable after all that polling and man, we were just polling this machine, so what's up?" is only for this test. 

I know that error code could mean that both sides are trying to compete for data from the socket at the same time, or that the other side just has not had a chance to come up yet, or heck, that the data is just unavailable and can come up at any time as long as we have no exceeded the timeout yet.

Here are some places that I found to demonstrate some twisted code using a portion of the above pattern but it isn't the one that I wanted to use as substantiation. The place that I wanted to share, unfortunately, is lost forever, in the sea of history I acquired while researching this problem.

- http://twistedmatrix.com/pipermail/twisted-python/2010-September/022863.html
- http://stackoverflow.com/a/3648261
- http://pydoc.net/Python/Twisted/14.0.2/twisted.internet.tcp/


-- 
To view, visit https://gerrit.asterisk.org/1055
To unsubscribe, visit https://gerrit.asterisk.org/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: Ica28ba0ca7ae92b3546da4cd23458f289c111d36
Gerrit-PatchSet: 6
Gerrit-Project: testsuite
Gerrit-Branch: master
Gerrit-Owner: Ashley Sanders <asanders at digium.com>
Gerrit-Reviewer: Ashley Sanders <asanders at digium.com>
Gerrit-Reviewer: Jonathan Rose <jrose at digium.com>
Gerrit-Reviewer: Joshua Colp <jcolp at digium.com>
Gerrit-Reviewer: Mark Michelson <mmichelson at digium.com>
Gerrit-HasComments: Yes