1diameter_transport(3) Erlang Module Definition diameter_transport(3)
2
6 diameter_transport - Diameter transport interface.
7
9 A module specified as a transport_module to diameter:add_transport/2
10 must implement the interface documented here. The interface consists of
11 a function with which diameter starts a transport process and a message
12 interface with which the transport process communicates with the
13 process that starts it (aka its parent).
14
16 message() = binary() | diameter_codec:packet():
17 A Diameter message as passed over the transport interface.
18 For an inbound message from a transport process, a diame‐
20 ter_codec:packet() must contain the received message in its bin
21 field. In the case of an inbound request, any value set in the
22 transport_data field will passed back to the transport module in
23 the corresponding answer message, unless the sender supplies
24 another value.
25 For an outbound message to a transport process, a diame‐
27 ter_codec:packet() has a value other than undefined in its trans‐
28 port_data field and has the binary() to send in its bin field.
29
31 Mod:start({Type, Ref}, Svc, Config) -> {ok, Pid} | {ok, Pid, LAddrs} |
32 {error, Reason}
33 Types:
35 Type = connect | accept
37 Ref = diameter:transport_ref()
38 Svc = #diameter_service{}
39 Config = term()
40 Pid = pid()
41 LAddrs = [inet:ip_address()]
42 Reason = term()
43 Start a transport process. Called by diameter as a consequence
45 of a call to diameter:add_transport/2 in order to establish or
46 accept a transport connection respectively. A transport process
47 maintains a connection with a single remote peer.
48 Type indicates whether the transport process in question is
50 being started for a connecting (Type=connect) or listening
51 (Type=accept) transport. In the latter case, transport processes
52 are started as required to accept connections from multiple
53 peers.
54 Ref is the value that was returned from the call to diame‐
56 ter:add_transport/2 that has lead to starting of a transport
57 process.
58 Svc contains capabilities passed to diameter:start_service/2 and
60 diameter:add_transport/2, values passed to the latter overriding
61 those passed to the former.
62 Config is as passed in transport_config tuple in the diame‐
64 ter:transport_opt() list passed to diameter:add_transport/2.
65 The start function should use the Host-IP-Address list in Svc
67 and/or Config to select and return an appropriate list of local
68 IP addresses. In the connecting case, the local address list can
69 instead be communicated in a connected message (see MESSAGES
70 below) following connection establishment. In either case, the
71 local address list is used to populate Host-IP-Address AVPs in
72 outgoing capabilities exchange messages if Host-IP-Address is
73 unspecified.
74 A transport process must implement the message interface docu‐
76 mented below. It should retain the pid of its parent, monitor
77 the parent and terminate if it dies. It should not link to the
78 parent. It should exit if its transport connection with its peer
79 is lost.
80
82 All messages sent over the transport interface are of the form {diame‐
83 ter, term()}.
84 A transport process can expect messages of the following types from its
86 parent.
87 {diameter, {send, message()}}:
89 An outbound Diameter message.
90 {diameter, {close, Pid}}:
92 A request to terminate the transport process after having received
93 DPA in response to DPR. The transport process should exit. Pid is
94 the pid() of the parent process.
95 {diameter, {tls, Ref, Type, Bool}}:
97 Indication of whether or not capabilities exchange has selected
98 inband security using TLS. Ref is a reference() that must be
99 included in the {diameter, {tls, Ref}} reply message to the trans‐
100 port's parent process (see below). Type is either connect or accept
101 depending on whether the process has been started for a connecting
102 or listening transport respectively. Bool is a boolean() indicating
103 whether or not the transport connection should be upgraded to TLS.
104 If TLS is requested (Bool=true) then a connecting process should
106 initiate a TLS handshake with the peer and an accepting process
107 should prepare to accept a handshake. A successful handshake should
108 be followed by a {diameter, {tls, Ref}} message to the parent
109 process. A failed handshake should cause the process to exit.
110 This message is only sent to a transport process over whose Inband-
112 Security-Id configuration has indicated support for TLS.
113 A transport process should send messages of the following types to its
115 parent.
116 {diameter, {self(), connected}}:
118 Inform the parent that the transport process with Type=accept has
119 established a connection with the peer. Not sent if the transport
120 process has Type=connect.
121 {diameter, {self(), connected, Remote}}:
123 {diameter, {self(), connected, Remote, [LocalAddr]}}:
126 Inform the parent that the transport process with Type=connect has
127 established a connection with a peer. Not sent if the transport
128 process has Type=accept. Remote is an arbitrary term that uniquely
129 identifies the remote endpoint to which the transport has con‐
130 nected. A LocalAddr list has the same semantics as one returned
131 from start/3.
132 {diameter, {recv, message()}}:
134 An inbound Diameter message.
135 {diameter, {tls, Ref}}:
137 Acknowledgment of a successful TLS handshake. Ref is the refer‐
138 ence() received in the {diameter, {tls, Ref, Type, Bool}} message
139 in response to which the reply is sent. A transport must exit if a
140 handshake is not successful.
141
143 diameter_tcp(3), diameter_sctp(3)
144Ericsson AB diameter 2.1.4.1 diameter_transport(3)