[erlang-questions] Erlang RPC over Diameter

Ulf Wiger (TN/EAB) <>
Thu Jun 21 16:28:20 CEST 2007

Given that a number (> 1) of Erlang people are hacking away at 
Diameter stacks, what would you think about agreeing on some
derived types for carrying erlang information?


Diameter is an RPC protocol, in that all communication consists
of request-response pairs. Authentication is being standardized,
and the Base Protocol supports end-to-end security via S-MIME.
It can run on TCP or SCTP, it can be proxied, and it's a pretty 
efficient byte-coded protocol (a rare treat nowadays.)

What's more? It has support for robust client-server communication,
in that the client will resend a request to a standby server if the 
first one goes down. And the encoding supports nested data 
structures. It also allows for load-balancing.

This could be used for loosely connecting Erlang-based nodes 
across an open network, but it would probably be wise to agree
on how Erlang data types should be encoded.

Different stacks will implement encode/decode differently.
In my stack, a callback module can be designated for 
custom types, and are expected to provide a function
for encode & decode respectively:

'ETerm'(encode, Term) -> term_to_binary(Term);
'ETerm'(decode, Bin)   -> binary_to_term(Bin).

'EInteger'(encode, I) when is_integer(I) -> <<I:32/integer>>;
'EInteger'(decode, <<I:32/integer>>) -> I.

... etc.

I haven't written a callback for Erlang types yet.
Diameter uses 32-bit aligned objects.

One could make it really easy, and encode/decode all
types as ETerm, and have specific types, EInteger, etc.
coded the same way, but restricted to the corresponding
Erlang types.

In Diameter parlance, ETerm would be a derived type 
based on the base type OctetString, but we would then
add the restriction that it conform to the Erlang Term format.

Tuples and lists should perhaps be grouped AVPs:

EList ::= < AVP Header : ??? >
              * [ ETerm ]

ETuple ::= < AVP Header : ??? >
               { Arity }
             * [ ETerm ]


Arity would be an AVP of type Unsigned32 (a base type)
and ETerm would be an AVP of type ETerm.

... Of course, you could do the same thing with CORBA,
but what would be the point of using something tried and 
true?  ;-)

At least, Diameter is much more efficient than SOAP.

Ulf W
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20070621/9de95220/attachment.html>

More information about the erlang-questions mailing list