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.
Version 0.9.6.10 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 . The reason for the license restrictions is that I don't want to compete directly with my current employer. Note: Due to mail server movement the above email address temporarily is only available over IPv6
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.