WriteLoop issues about sctp HOT 4 CLOSED

Thanks @backkem, great catch! Looks like the goroutine for T3-rtx timer is still active. (probably other timers, too) These are cleaned up when association.Close() with the current code, and it probably needs to be cleaned up when writeLoop ends also...

from sctp.

Hmm, I see this also in your log:

sctp DEBUG: 13:53:52.877254 association.go:499: retransmitting 900 bytes

The writeLoop has not ended with some node... I guess I need to improve the log message to dig deeper.

from sctp.

I confirmed SubtestPingPong test fails on my mac as well.
Looking at the log (the improved one I just pushed to writeLoop branch), there are two nodes (associations). One end terminates (I can see "writeLoop ended" and "closing association.."), but the other keeps trying to retransmit packets for about 45 seconds, then finally sees an write error on netConn. (I guess it never receives association.Close() and write succeeds during the 45 seconds (netConn is still open)...

from sctp.

@bacckem
With the test, SubtestStress50Conn10Stream50Msg, I was able to see some nodes firing times even though writeLoop exited.

I added a code to clean up timers when exiting writeLoop - I pushed the change to the branch. I ran the same test, SubtestStress50Conn10Stream50Msg, I no longer see a node firing rtx timeout after writeLoop exits, so it looks a bit clearner on the log but, I still see some nodes trying to retransmit packets on T3-rtx timeout but from the log. Those nodes never see association.Close() nor write error on netConn, so again, dtls is still open and writeLoop is (legitimately) running, I think.

from sctp.