<feed xmlns='http://www.w3.org/2005/Atom'>
<title>otp.git/lib/diameter/src/base, branch OTP-18.2.3</title>
<subtitle>Mirror of Erlang/OTP repository.
</subtitle>
<link rel='alternate' type='text/html' href='http://git.ninenines.eu/otp.git/'/>
<entry>
<title>Merge branch 'anders/diameter/request_leak/OTP-13137' into maint</title>
<updated>2015-12-09T14:11:52+00:00</updated>
<author>
<name>Anders Svensson</name>
<email>anders@erlang.org</email>
</author>
<published>2015-12-09T14:11:52+00:00</published>
<link rel='alternate' type='text/html' href='http://git.ninenines.eu/otp.git/commit/?id=0dc640a73faba6e3f00d45e6b2739ce055d977cd'/>
<id>0dc640a73faba6e3f00d45e6b2739ce055d977cd</id>
<content type='text'>
* anders/diameter/request_leak/OTP-13137:
  Fix request table leak at retransmission
  Fix request table leak at exit signal
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* anders/diameter/request_leak/OTP-13137:
  Fix request table leak at retransmission
  Fix request table leak at exit signal
</pre>
</div>
</content>
</entry>
<entry>
<title>Fix request table leak at retransmission</title>
<updated>2015-12-09T12:32:18+00:00</updated>
<author>
<name>Anders Svensson</name>
<email>anders@erlang.org</email>
</author>
<published>2015-12-03T12:09:11+00:00</published>
<link rel='alternate' type='text/html' href='http://git.ninenines.eu/otp.git/commit/?id=6c9cbd96d01da3194715d3caf8aa23350dfaa53a'/>
<id>6c9cbd96d01da3194715d3caf8aa23350dfaa53a</id>
<content type='text'>
In the case of retranmission, a prepare_retransmit callback could modify
End-to-End and/or Hop-by-Hop identifiers so that the resulting
diameter_request entry was not removed, since the removal was of entries
with the identifiers of the original request. The chances someone doing
this in practice are probably minimal.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
In the case of retranmission, a prepare_retransmit callback could modify
End-to-End and/or Hop-by-Hop identifiers so that the resulting
diameter_request entry was not removed, since the removal was of entries
with the identifiers of the original request. The chances someone doing
this in practice are probably minimal.
</pre>
</div>
</content>
</entry>
<entry>
<title>Fix request table leak at exit signal</title>
<updated>2015-12-09T12:31:22+00:00</updated>
<author>
<name>Anders Svensson</name>
<email>anders@erlang.org</email>
</author>
<published>2015-12-01T07:11:25+00:00</published>
<link rel='alternate' type='text/html' href='http://git.ninenines.eu/otp.git/commit/?id=f8fa795ac4885af5c9f396fbcf26143a67fbdf49'/>
<id>f8fa795ac4885af5c9f396fbcf26143a67fbdf49</id>
<content type='text'>
The storing of request records in the ets table diameter_request was
wrapped in a try/after so that the latter would unconditionally remove
written entries. The problem is that it didn't deal with the process
exiting as a result of an exit signal, since this doesn't raise in an
exception. Since the process in question applies callbacks to user code,
we can potentially be linked to other process and exit as a result.
Trapping exits changes the current behaviour of the process, so spawn a
monitoring process that cleans up upon reception of 'DOWN'.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The storing of request records in the ets table diameter_request was
wrapped in a try/after so that the latter would unconditionally remove
written entries. The problem is that it didn't deal with the process
exiting as a result of an exit signal, since this doesn't raise in an
exception. Since the process in question applies callbacks to user code,
we can potentially be linked to other process and exit as a result.
Trapping exits changes the current behaviour of the process, so spawn a
monitoring process that cleans up upon reception of 'DOWN'.
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge branch 'anders/diameter/watchdog/OTP-12969' into maint</title>
<updated>2015-09-14T21:41:52+00:00</updated>
<author>
<name>Anders Svensson</name>
<email>anders@erlang.org</email>
</author>
<published>2015-09-14T21:41:52+00:00</published>
<link rel='alternate' type='text/html' href='http://git.ninenines.eu/otp.git/commit/?id=33666085c11ffdd0c931042dd742f1b1fae35543'/>
<id>33666085c11ffdd0c931042dd742f1b1fae35543</id>
<content type='text'>
* anders/diameter/watchdog/OTP-12969:
  Fix watchdog function_clause
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* anders/diameter/watchdog/OTP-12969:
  Fix watchdog function_clause
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge branch 'anders/diameter/M-bit/OTP-12947' into maint</title>
<updated>2015-09-14T21:41:46+00:00</updated>
<author>
<name>Anders Svensson</name>
<email>anders@erlang.org</email>
</author>
<published>2015-09-14T21:41:46+00:00</published>
<link rel='alternate' type='text/html' href='http://git.ninenines.eu/otp.git/commit/?id=a8d17f7e69e853d1bc858e72dc9daf6beed30f19'/>
<id>a8d17f7e69e853d1bc858e72dc9daf6beed30f19</id>
<content type='text'>
* anders/diameter/M-bit/OTP-12947:
  Add service_opt() strict_mbit
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* anders/diameter/M-bit/OTP-12947:
  Add service_opt() strict_mbit
</pre>
</div>
</content>
</entry>
<entry>
<title>Fix watchdog function_clause</title>
<updated>2015-09-07T15:54:27+00:00</updated>
<author>
<name>Anders Svensson</name>
<email>anders@erlang.org</email>
</author>
<published>2015-09-07T14:57:30+00:00</published>
<link rel='alternate' type='text/html' href='http://git.ninenines.eu/otp.git/commit/?id=f616bf9f03feb8d9601a4c6ece552e13ec492fb8'/>
<id>f616bf9f03feb8d9601a4c6ece552e13ec492fb8</id>
<content type='text'>
Commit 4f365c07 introduced the error on set_watchdog/2, as a consequence
of timeout/1 returning stop, which only happens with accepting
transports with {restrict_connections, false}.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Commit 4f365c07 introduced the error on set_watchdog/2, as a consequence
of timeout/1 returning stop, which only happens with accepting
transports with {restrict_connections, false}.
</pre>
</div>
</content>
</entry>
<entry>
<title>Add service_opt() strict_mbit</title>
<updated>2015-08-24T22:03:03+00:00</updated>
<author>
<name>Anders Svensson</name>
<email>anders@erlang.org</email>
</author>
<published>2015-08-24T14:14:49+00:00</published>
<link rel='alternate' type='text/html' href='http://git.ninenines.eu/otp.git/commit/?id=502189ba42469d3332bc0658caa2bd0de1e3fcb9'/>
<id>502189ba42469d3332bc0658caa2bd0de1e3fcb9</id>
<content type='text'>
There are differing opinions on whether or not reception of an arbitrary
AVP setting the M-bit is an error. 1.3.4 of RFC 6733 says this about
how an existing Diameter application may be modified:

   o  The M-bit allows the sender to indicate to the receiver whether or
      not understanding the semantics of an AVP and its content is
      mandatory.  If the M-bit is set by the sender and the receiver
      does not understand the AVP or the values carried within that AVP,
      then a failure is generated (see Section 7).

   It is the decision of the protocol designer when to develop a new
   Diameter application rather than extending Diameter in other ways.
   However, a new Diameter application MUST be created when one or more
   of the following criteria are met:

   M-bit Setting

      An AVP with the M-bit in the MUST column of the AVP flag table is
      added to an existing Command/Application.  An AVP with the M-bit
      in the MAY column of the AVP flag table is added to an existing
      Command/Application.

The point here is presumably interoperability: that the command grammar
should specify explicitly what mandatory AVPs much be understood, and
that anything more is an error.

On the other hand, 3.2 says thus about command grammars:

   avp-name         = avp-spec / "AVP"
                      ; The string "AVP" stands for *any* arbitrary AVP
                      ; Name, not otherwise listed in that Command Code
                      ; definition.  The inclusion of this string
                      ; is recommended for all CCFs to allow for
                      ; extensibility.

This renders 1.3.4 pointless unless "*any* AVP" is qualified by "not
setting the M-bit", since the sender can effectively violate 1.3.4
without this necessitating an error at the receiver. If clients add
arbitrary AVPs setting the M-bit then request handling becomes more
implementation-dependent.

The current interpretation in diameter is strict: if a command grammar
doesn't explicitly allow an AVP setting the M-bit then reception of such
an AVP is regarded as an error. The strict_mbit option now allows this
behaviour to be changed, false turning all responsibility for the M-bit
over to the user.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
There are differing opinions on whether or not reception of an arbitrary
AVP setting the M-bit is an error. 1.3.4 of RFC 6733 says this about
how an existing Diameter application may be modified:

   o  The M-bit allows the sender to indicate to the receiver whether or
      not understanding the semantics of an AVP and its content is
      mandatory.  If the M-bit is set by the sender and the receiver
      does not understand the AVP or the values carried within that AVP,
      then a failure is generated (see Section 7).

   It is the decision of the protocol designer when to develop a new
   Diameter application rather than extending Diameter in other ways.
   However, a new Diameter application MUST be created when one or more
   of the following criteria are met:

   M-bit Setting

      An AVP with the M-bit in the MUST column of the AVP flag table is
      added to an existing Command/Application.  An AVP with the M-bit
      in the MAY column of the AVP flag table is added to an existing
      Command/Application.

The point here is presumably interoperability: that the command grammar
should specify explicitly what mandatory AVPs much be understood, and
that anything more is an error.

On the other hand, 3.2 says thus about command grammars:

   avp-name         = avp-spec / "AVP"
                      ; The string "AVP" stands for *any* arbitrary AVP
                      ; Name, not otherwise listed in that Command Code
                      ; definition.  The inclusion of this string
                      ; is recommended for all CCFs to allow for
                      ; extensibility.

This renders 1.3.4 pointless unless "*any* AVP" is qualified by "not
setting the M-bit", since the sender can effectively violate 1.3.4
without this necessitating an error at the receiver. If clients add
arbitrary AVPs setting the M-bit then request handling becomes more
implementation-dependent.

The current interpretation in diameter is strict: if a command grammar
doesn't explicitly allow an AVP setting the M-bit then reception of such
an AVP is regarded as an error. The strict_mbit option now allows this
behaviour to be changed, false turning all responsibility for the M-bit
over to the user.
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge branch 'maint-17' into maint</title>
<updated>2015-08-13T21:01:28+00:00</updated>
<author>
<name>Anders Svensson</name>
<email>anders@erlang.org</email>
</author>
<published>2015-08-13T15:08:15+00:00</published>
<link rel='alternate' type='text/html' href='http://git.ninenines.eu/otp.git/commit/?id=8c5d719afaeae0c9cfa1079c0de5452f8bdc837b'/>
<id>8c5d719afaeae0c9cfa1079c0de5452f8bdc837b</id>
<content type='text'>
The diffs are all about adapting to the OTP 18 time interface. The code
was previously backwards compatible, falling back on the erlang:now/0 if
erlang:monotonic_time/0 is unavailable, but this was seen to be a bad
thing in commit 9c0f2f2c. Use of erlang:now/0 is now removed.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The diffs are all about adapting to the OTP 18 time interface. The code
was previously backwards compatible, falling back on the erlang:now/0 if
erlang:monotonic_time/0 is unavailable, but this was seen to be a bad
thing in commit 9c0f2f2c. Use of erlang:now/0 is now removed.
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge branch 'anders/diameter/17/time/OTP-12926' into maint-17</title>
<updated>2015-08-13T10:34:03+00:00</updated>
<author>
<name>Erlang/OTP</name>
<email>otp@erlang.org</email>
</author>
<published>2015-08-13T10:34:03+00:00</published>
<link rel='alternate' type='text/html' href='http://git.ninenines.eu/otp.git/commit/?id=2c7132e3f6dc670a177aac804fe12702dbc9ed7d'/>
<id>2c7132e3f6dc670a177aac804fe12702dbc9ed7d</id>
<content type='text'>
* anders/diameter/17/time/OTP-12926:
  Simplify time manipulation
  Remove use of monotonic time in pre-18 code
  Remove unnecessary redefinition of erlang:max/2
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* anders/diameter/17/time/OTP-12926:
  Simplify time manipulation
  Remove use of monotonic time in pre-18 code
  Remove unnecessary redefinition of erlang:max/2
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge branch 'anders/diameter/grouped_errors/OTP-12930' into maint-17</title>
<updated>2015-08-13T10:34:03+00:00</updated>
<author>
<name>Erlang/OTP</name>
<email>otp@erlang.org</email>
</author>
<published>2015-08-13T10:34:03+00:00</published>
<link rel='alternate' type='text/html' href='http://git.ninenines.eu/otp.git/commit/?id=0c21fb612b736f53dcc04face42bd106c50287ae'/>
<id>0c21fb612b736f53dcc04face42bd106c50287ae</id>
<content type='text'>
* anders/diameter/grouped_errors/OTP-12930:
  Fix decode of Grouped AVPs containing errors
  Simplify logic
  Simplify logic
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* anders/diameter/grouped_errors/OTP-12930:
  Fix decode of Grouped AVPs containing errors
  Simplify logic
  Simplify logic
</pre>
</div>
</content>
</entry>
</feed>
