Fix start order of alternate transports

A transport configured with diameter:add_transport/2 can be passed
multiple transport_module/transport_config tuples in order to specify
alternate configuration, modules being attempted in order until one
succeeds. This is primarily for the connecting case, to allow a
transport to be configured to first attempt connection over SCTP, and
then TCP in case SCTP fails, with configuration like that documented:

  {transport_module, diameter_sctp},
  {transport_config, [...], 5000},
  {transport_module, diameter_tcp},
  {transport_config, [...]}

If the options are the same in both cases, another possibility would be
configuration like this, which attaches the same transport_config to
both modules:

  {transport_module, diameter_sctp},
  {transport_module, diameter_tcp},
  {transport_config, [...], 5000},

However, in this case the start order was reversed relative to the
documented order: first tcp, then sctp. This commit restores the
intended order.

0 files changed, 0 insertions, 0 deletions