diff options
author | Anders Svensson <[email protected]> | 2015-03-06 02:24:28 +0100 |
---|---|---|
committer | Anders Svensson <[email protected]> | 2015-03-22 09:59:14 +0100 |
commit | 5bd2d72eeede1ddc13fcaf483d48d88833c691da (patch) | |
tree | ef698d6da827610bedfb8c7ded9f7e00fc19b175 /lib/diameter/src/base/diameter_app.erl | |
parent | af87b1c3d4897840d8247589a88d3611106ecedc (diff) | |
download | otp-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_app.erl')
0 files changed, 0 insertions, 0 deletions