From f1ffd33240b982ec2ed80231a3a10f14cf5e3fc9 Mon Sep 17 00:00:00 2001
From: Anders Svensson
+
+
+
+&man_main;,
+&man_dict;
+
+
+&man_main;,
+&man_dict;
An address list is available to the start function of a
-
The
Note that a single
The representation of a Diameter message as passed to
-&mod_call;.
-The record representation is as outlined in
-
-A third representation allows a message to be specified as a list
-whose head is a
A container for incoming and outgoing Diameter messages that's passed
@@ -505,8 +486,7 @@ The application in which the callback takes place (that is, the
callback module as configured with &mod_start_service;)
is determined by the Application Identifier in the header of the
incoming request message, the selected module being the one
-whose corresponding
The
-
+Calls to this module are made by diameter itself as a consequence of +configuration passed to &mod_start_service;. +The encode/decode functions may also be useful for other purposes (eg. +test) but the diameter user does not need to call them explicitly when +sending and receiving messages using &mod_call; and the callback +interface documented in &man_app;.
++The &header; and &packet; records below +are defined in diameter.hrl, which can be included as follows.
+ ++-include_lib("diameter/include/diameter.hrl"). ++ +
+Application-specific records are definied in the hrl +files resulting from dictionary file compilation.
++8-bit, 24-bit and 32-bit integers occurring in Diameter and AVP +headers.
++The application-neutral representation of an AVP. +Primarily intended for use by relay applications that need to handle +arbitrary Diameter applications. +A service implementing a specific Diameter application +(for which it configures a dictionary) can manipulate values of type +&message; instead.
+ ++Fields have the following types.
+ +
+Values in the AVP header, corresponding to AVP Code, the M flag, P
+flags and Vendor-ID respectivelty.
+A Vendor-ID other than
+The data bytes of the AVP.
+
+The name of the AVP as defined in the dictionary file in question, or
+
+The decoded value of an AVP.
+Will be
+The type of the AVP as specified in the dictionary file in question
+(or one it inherits).
+Possible types are
+The name of a generated dictionary module as generated by &man_compile; +or &make_codec;. +The interface provided by a dictionary module is an +implementation detail that may change.
+
+The record representation of the Diameter header.
+Values in a &packet; returned by &decode; are as extracted from the
+incoming message.
+Values set in an &packet; passed to &encode; are preserved in the
+encoded binary(), with the exception of
+It is not necessary to set header fields explicitly in outgoing +messages as diameter itself will set appropriate values. +Setting inappropriate values can be useful for test purposes.
++Fields have the following types.
+ ++Values of the Version, Message Length, Command-Code, Application-ID, +Hop-by-Hop Identifier and End-to-End Identifier fields of the Diameter +header.
++Values correspoding to the R(equest), P(roxiable), E(rror) +and T(Potentially re-transmitted message) flags of the Diameter +header.
+
+The representation of a Diameter message as passed to
+&mod_call; or returned from a &app_handle_request; callback.
+The record representation is as outlined in &records;:
+a message as defined in a dictionary file is encoded as a record with
+one field for each component AVP.
+Equivalently, a message can also be encoded as a list whose head is
+the atom-valued message name (as specified in the relevant dictionary
+file) and whose tail is a list of
+Another list-valued representation allows a message to be specified +as a list whose head is a &header; and whose tail is an &avp; list. +This representation is used by diameter itself when relaying requests +as directed by the return value of a &app_handle_request; callback. +It differs from the other other two in that it bypasses the checks for +messages that do not agree with their definitions in the dictionary in +question: messages are sent exactly as specified.
+ ++A container for incoming and outgoing Diameter messages. +Fields have the following types.
+ +-
+Decode a Diameter message.+Encode a Diameter message.
-&man_main;, -&man_dict;
+&man_compile;, &man_app;, &man_dict;, &man_make; diff --git a/lib/diameter/doc/src/diameter_compile.xml b/lib/diameter/doc/src/diameter_compile.xml index eb6de80c11..0bd7ad1789 100644 --- a/lib/diameter/doc/src/diameter_compile.xml +++ b/lib/diameter/doc/src/diameter_compile.xml @@ -1,5 +1,7 @@ dictionary file'> %also; @@ -36,12 +38,14 @@ supplied.
-The diameterc utility is used to compile diameter
-
+The module &man_make; provides an alternate compilation interface.
+-Compiles a single dictionary file. Valid options are as follows.
- - - --Specifies the directory into which the generated source should be written. -Defaults to the current working directory.
-
-Specifies a directory to add to the code path.
+Prepend the specified directory to the code path.
Use to point at beam files compiled from inherited dictionaries,
-
Multiple
+Write generated source to the specified directory. +Defaults to the current working directory.
+-Supresses erl and hrl generation, respectively.
+Supress erl and hrl generation, respectively.
-Set
-Append an
Multiple
-&man_dict;
+&man_make;, &man_dict;
-A diameter service as configured with &mod_start_service;
+A diameter service, as configured with &mod_start_service;,
specifies one or more supported Diameter applications.
Each Diameter application specifies a dictionary module that knows how
to encode and decode its messages and AVPs.
The dictionary module is in turn generated from a file that defines
these messages and AVPs.
-The format of such a file is defined in
-
-The codec generation also results in a hrl file that defines records
-for the messages and grouped AVPs defined for the application, these
-records being what a user of the diameter application sends and receives.
-(Modulo other available formats as discussed in &man_app;.)
+Dictionary module generation also results in a hrl file that defines
+records for the messages and Grouped AVPs defined by the
+dictionary, these records being what a user of the diameter
+application sends and receives, modulo other possible formats as
+discussed in &man_app;.
These records and the underlying Erlang data types corresponding to
-Diameter data formats are discussed in
@@ -111,6 +116,8 @@ The order in which sections are specified is unimportant.
@@ -134,6 +141,8 @@ Example:
@@ -155,6 +164,8 @@ Example:
@@ -178,6 +189,8 @@ Example:
@@ -198,6 +211,8 @@ Example:
@@ -218,6 +233,8 @@ Region-Set
@@ -253,6 +270,8 @@ Example:
@@ -263,7 +282,7 @@ The section consists of definitions of the form
where Code is the integer AVP code, Type identifies an AVP Data Format
-as defined in
@@ -308,6 +329,8 @@ Framed-IP-Address
@@ -325,6 +348,8 @@ Framed-IP-Address
@@ -370,6 +395,8 @@ RTA ::= < Diameter Header: 287, PXY >
@@ -395,6 +422,8 @@ Specifying a Vendor-Id in the definition of a grouped AVP is
equivalent to specifying it with
@@ -421,6 +450,8 @@ REMOVE_SIP_SERVER 3
@@ -447,8 +478,8 @@ The hrl generated from a dictionary specification defines records for the
messages and grouped AVPs defined in
-&man_compile;, &man_main;, &man_app;
+&man_compile;, &man_main;, &man_app;, &man_codec;, &man_make; diff --git a/lib/diameter/doc/src/diameter_make.xml b/lib/diameter/doc/src/diameter_make.xml index aee98d62d2..da6124310e 100644 --- a/lib/diameter/doc/src/diameter_make.xml +++ b/lib/diameter/doc/src/diameter_make.xml @@ -1,5 +1,9 @@ file:name()'> + dictionary file'> %also; @@ -43,7 +47,14 @@ under the License.-
+The function &codec; is used to compile a diameter +&dictionary; into Erlang source. +The resulting source implements the interface diameter required +to encode and decode the dictionary's messages and AVP's. + ++The utility &man_compile; provides an alternate compilation +interface.
-
+Compile a single dictionary file to Erlang source. +
+Prepend the specified directory to the code path.
+Use to point at beam files compiled from inherited dictionaries,
+
+Multiple
+Write generated source to the specified directory. +Defaults to the current working directory.
+
+Set
+Append &dict_inherits; of the specified module.
+Specifying
+Multiple
+All options are string-valued. +In particular, it is not currently possible to +an &dict_inherits; module as an atom() or a path as a &filename;
+ +-&man_main;, -&man_dict;
+&man_compile;, &man_dict;
-This module implements diameter transport over SCTP using
An insufficiently large receive buffer may result in a peer having to
-resend incoming messages: set the
An insufficiently large send buffer may result in outgoing messages
-being discarded: set the
-&man_main;,
-&man_transport;,
-
-This module implements diameter transport over TCP using
-&man_main;,
-&man_transport;,
-
+A Diameter message as passed over the transport interface.
+ +
+For an inbound message from a transport process, a &codec_packet; must
+contain the received message in its
+For an outbound message to a transport process, a &codec_packet; has a
+value other than
The start function should use the
-A transport process can expect the following messages from -diameter.
+A transport process can expect messages of the following types from +its parent.
-An outbound Diameter message.
-
-A transport process should send the following messages +A transport process should send messages of the following types to its parent.
-An inbound Diameter message.
-
-The function &service_info;
+The function diameter:service_info/2
can be used to retrieve information about a started service
(statistics, information about connected peers, etc) but
this is not yet documented and both the input and output may change
diff --git a/lib/diameter/doc/src/seealso.ent b/lib/diameter/doc/src/seealso.ent
index 6f67630220..435dfda326 100644
--- a/lib/diameter/doc/src/seealso.ent
+++ b/lib/diameter/doc/src/seealso.ent
@@ -77,12 +77,21 @@ significant.
prepare_request/3'>
diameter_app:capabilities()'>
-diameter_app:message()'>
-diameter_app:packet()'>
diameter_app:peer()'>
diameter_app:peer_ref()'>
diameter_app:state()'>
+
+
+diameter_codec:encode/2'>
+diameter_codec:decode/2'>
+
+diameter_codec:avp()'>
+diameter_codec:header()'>
+diameter_codec:dictionary()'>
+diameter_codec:message()'>
+diameter_codec:packet()'>
+
diameter_dict(4)'>
@@ -95,6 +104,14 @@ significant.
UTF8String()'>
Unsigned32()'>
+@name'>
+@prefix'>
+@inherits'>
+
+
+
+diameter_make:codec/2'>
+
diameterc(1)'>
diameter(3)'>
diameter_app(3)'>
+diameter_codec(3)'>
diameter_dict(4)'>
-diameter_transport(3)'>
+diameter_make(3)'>
+diameter_transport(3)'>
diameter_sctp(3)'>
diameter_tcp(3)'>
--
cgit v1.2.3
From 3b8adac9179ea32c2f78860c621289cb4b2bb57e Mon Sep 17 00:00:00 2001
From: Anders Svensson
+The Diameter header of the message.
+Can be (and typically should be)
+The AVPs of the message.
+Ignored for an outgoing message if the
+The incoming/outgoing message.
+For an incoming message, a record if the message can be
+decoded in a non-relay application,
+A record-valued
+The incoming message prior to encode or the outgoing message after +encode.
+Errors detected at decode of an incoming message, as identified by
+a corresponding 5xxx series Result-Code (Permanent Failures).
+For an incoming request, these should be used to formulate an
+appropriate answer as documented for the &app_handle_request;
+callback in &man_app;.
+For an incoming answer, the &mod_application_opt;
+
+An arbitrary term of meaning only to the transport process in +question, as documented in &man_transport;.