Java Diameter Library

Java Diameter Library

This page describes a Java Diameter (see RFC 3588) API/stack that I made.

The API is not based on the C/Java diameter API draft. Dictionaries, XML files, and variant records are not exactly my cup of tea.

This implementation of the Diameter protocol is written in Java (5.0). It is based on RFC 3588. There are examples for using something on top of the Diameter stack such as AAR/AAA messages, accounting, abort-session-requests, a small load test tool, and so on. The library itself is unaware of the specific diameter applications using it. Using this diameter library you can implement NASREQ (RFC 4005), EAP-based authentication (RFC 4072), Credit-Control (RFC 4006), SIP (currently draft, focusing on VoIP and multimedia) or even some of the 3GPP applications.


I am a C++ programmer. I have always wondered if Java is really as slow as most C++ programmers think. There are no good benchmarks on this as the two languages tend to be used for different things, and the only benchmarks available are in the style of "loop through 10000 integers and count the sum" or similar which is completely irrevelant for real programs.

So I implemented a complete Diameter stack which involves network I/O, message encoding/decoding, queue management, and a fair amount of logic.


You can browse the complete documentation for the Java Diameter API.


New: source code is now available on github isj4/JavaDiameter repository

Version is out, and adds support for specifying the TCP source port range, request timeouts, and a few minor fixes.

You should read the LICENSE first. You can get the .jar-file, the documentation (same as above, but for offline purposes), and examples and tools by going here.

If you cannot accept the license then try contacting me at obfuscated email address.

Ok, what about the performance?

I am not at liberty to give the exact performance numbers comparing with a C++ implementation. I can say that if Java programs do not wrap everything into 117 layers of abstraction (which Java programmers tend to do) then Java's performance is quite good. But I will stick to C++ for network applications, though.