aboutsummaryrefslogtreecommitdiffstats
path: root/lib/diameter/src/base/diameter_watchdog.erl
diff options
context:
space:
mode:
authorAnders Svensson <[email protected]>2015-03-06 02:24:28 +0100
committerAnders Svensson <[email protected]>2015-03-22 09:59:14 +0100
commit5bd2d72eeede1ddc13fcaf483d48d88833c691da (patch)
treeef698d6da827610bedfb8c7ded9f7e00fc19b175 /lib/diameter/src/base/diameter_watchdog.erl
parentaf87b1c3d4897840d8247589a88d3611106ecedc (diff)
downloadotp-5bd2d72eeede1ddc13fcaf483d48d88833c691da.tar.gz
otp-5bd2d72eeede1ddc13fcaf483d48d88833c691da.tar.bz2
otp-5bd2d72eeede1ddc13fcaf483d48d88833c691da.zip
Discard outgoing requests after outgoing DPR
RFC 6733 isn't terribly clear about what should happen to incoming or outgoing messages once DPR is sent and the Peer State Machine transitions into state Closing. There's no event for this in section 5.6, Peer State Machine, and no clarification in section 5.4, Disconnecting Peer Connections. There is a little bit of discussion in 2.1.1, SCTP Guidelines, in relation to unordered message delivery, but the tone there is that messages might be received after DPR because of unordered delivery, not because they were actually sent after DPR. Discarding outgoing answers may do more harm than good, but requests are more likely to be unexpected, as has been seen to be the case with DWR following DPR. DPR indicates a desire to close the connection: discard any subsequent outgoing requests.
Diffstat (limited to 'lib/diameter/src/base/diameter_watchdog.erl')
0 files changed, 0 insertions, 0 deletions