diameter_transport(3erl)

🌸 diameter_transport — Diameter transport interface 🌸

Erlang Module Definition, manual name diameter_transport(3erl), and yes bestie, this is the Diameter transport interface. It’s lowkey iconic because it’s the blueprint every transport module has to follow. 💅

✨ NAME ✨

• diameter_transport — the Diameter transport interface. Periodt.

🦋 DESCRIPTION 🦋

So, a module that you specify as a transport_module to diameter:add_transport/2 has to implement the interface documented right here. No cap. The interface is two things: a function that diameter uses to start a transport process, and a message interface that the transport process uses to talk to the process that starts it — aka its parent. 🫶

🎀 DATA TYPES 🎀

message() = binary() | diameter_codec:packet()

A Diameter message as it gets passed over the transport interface. 💌

For an inbound message from a transport process, a diameter_codec:packet() must contain the received message in its bin field. If it’s an inbound request, any value set in the transport_data field will be passed back to the transport module in the corresponding answer message — unless the sender supplies another value. 🙈

For an outbound message to a transport process, a diameter_codec:packet() has a value other than undefined in its transport_data field, and it has the binary() to send in its bin field. Slay. ✨

💅 EXPORTS 💅

⭐ Mod:start({Type, Ref}, Svc, Config) -> {ok, Pid} | {ok, Pid, LAddrs} | {error, Reason}

Types, bestie:

Type = connect | accept
Ref = diameter:transport_ref()
Svc = #diameter_service{}
Config = term()
Pid = pid()
LAddrs = [inet:ip_address()]
Reason = term()

Start a transport process. diameter calls this as a consequence of a call to diameter:add_transport/2, to establish or accept a transport connection respectively. A transport process maintains a connection with a single remote peer. One peer, one vibe. 👑

Type tells you whether the transport process in question is being started for a connecting transport (Type=connect) or a listening transport (Type=accept). In the latter case, transport processes are started as required to accept connections from multiple peers. 💫

Ref is the value that was returned from the call to diameter:add_transport/2 that has lead to starting of a transport process. Yep, that exact ref. 🎀

Svc contains capabilities passed to diameter:start_service/2 and diameter:add_transport/2 — and values passed to the latter override those passed to the former. The newer config wins, periodt. 💥

Config is as passed in the transport_config tuple in the diameter:transport_opt() list passed to diameter:add_transport/2. Keep it cute and keep it exact. 🌈

The start function should use the Host-IP-Address list in Svc and/or Config to select and return an appropriate list of local IP addresses. In the connecting case, the local address list can instead be communicated in a connected message — see MESSAGES below — following connection establishment. In either case, the local address list is used to populate Host-IP-Address AVPs in outgoing capabilities exchange messages if Host-IP-Address is unspecified. 🧚

A transport process must implement the message interface documented below. It should retain the pid of its parent, monitor the parent, and terminate if it dies. It should not link to the parent. It should exit if its transport connection with its peer is lost. That’s the rules, bestie. 💀

🦋 MESSAGES 🦋

All messages sent over the transport interface are of the form {diameter, term()}. That’s the envelope, always. 💌

📥 Messages the transport process can expect from its parent

A transport process can expect messages of the following types from its parent.

• {diameter, {send, message() | false}} — an outbound Diameter message. The atom false can only be received when request acknowledgements have been requested — see the ack message below. 👀
• {diameter, {close, Pid}} — a request to terminate the transport process after having received DPA in response to DPR. The transport process should exit. Pid is the pid() of the parent process. Bye bestie. 👋
• {diameter, {tls, Ref, Type, Bool}} — an indication of whether or not capabilities exchange has selected inband security using TLS. Ref is a reference() that must be included in the {diameter, {tls, Ref}} reply message to the transport’s parent process (see below). Type is either connect or accept depending on whether the process has been started for a connecting or listening transport respectively. Bool is a boolean() indicating whether or not the transport connection should be upgraded to TLS. 🔐

If TLS is requested (Bool=true) then a connecting process should initiate a TLS handshake with the peer, and an accepting process should prepare to accept a handshake. A successful handshake should be followed by a {diameter, {tls, Ref}} message to the parent process. A failed handshake should cause the process to exit. No half-vibes handshakes allowed. 😭

This message is only sent to a transport process over whose Inband-Security-Id configuration has indicated support for TLS. Check the config, iykyk. 💅

📤 Messages the transport process should send to its parent

A transport process should send messages of the following types to its parent.

• {diameter, {self(), connected}} — inform the parent that the transport process with Type=accept has established a connection with the peer. Not sent if the transport process has Type=connect. 💖
• {diameter, {self(), connected, Remote}} and {diameter, {self(), connected, Remote, [LocalAddr]}} — inform the parent that the transport process with Type=connect has established a connection with a peer. Not sent if the transport process has Type=accept. Remote is an arbitrary term that uniquely identifies the remote endpoint to which the transport has connected. A LocalAddr list has the same semantics as one returned from start/3. Remote bestie identified. 🌍
• {diameter, ack} — request acknowledgements of unanswered requests. A transport process should send this once before passing incoming Diameter messages into diameter. As a result, every Diameter request passed into diameter with a recv message (below) will be answered with a send message (above), either a message() for the transport process to send or the atom false if the request has been discarded or otherwise not answered. 🫶

This is to allow a transport process to keep count of the number of incoming request messages that have not yet been answered or discarded, to allow it to regulate the amount of incoming traffic. Both diameter_tcp and diameter_sctp request acknowledgements when a message_cb is configured, turning send/recv message into callbacks that can be used to regulate traffic. That’s the traffic-control fantasy, no cap. 🔥

• {diameter, {recv, message()}} — an inbound Diameter message. Come on in. 📨
• {diameter, {tls, Ref}} — acknowledgment of a successful TLS handshake. Ref is the reference() received in the {diameter, {tls, Ref, Type, Bool}} message in response to which the reply is sent. A transport must exit if a handshake is not successful. Successful handshake only, bestie. 🎀

🔥 SEE ALSO 🔥

• diameter_tcp(3erl)
• diameter_sctp(3erl)

---

💖 Cute little sign-off: this page is brought to you by Ericsson AB, version diameter 2.2.7, page diameter_transport(3erl). The original footer doesn’t list a date, so no invented date from me — just source/version/page realness. Mwah. 💋