Feature

A full load of modern web technology


Features


Multi Language Support

Connectanum contains a java message broker server and a fitting java client that can connect to the message broker. Thanks to the standardized protocol there are multiple clients that can connect to the connectanum router.

Languages: Java, JavaScript, C++, Python, Erlang, Haskell, Lua, Objective-C, PHP, Ruby, Go, C#

Tested to work with connectanum in production:

  • Java: connectanum client
  • JavaScript: Autobahn|JS is a well maintained client that works across all commonly used browsers and node.js. It can be combined with angular-wamp to use the domain-wide reactivity in your angular projects.
  • C++: Autobahn|Cpp is a well maintained client to use with your c++ code that has some minor limitations.

Super fast

Connectanum is Netty driven! Netty is trusted by hundreds of Java NIO-Projects like Twitter, Spotify, Minecraft, 1&1, Cisco and lots more. Connectanum only adds a flat netty codec on top of the default HTTP and WebSocket handlers which makes it a very fast piece of code.

Connectanum can handle as many connections as you need. Netty was tested with more then a million open connections. Depending on your scaling setup and machine, the router can easily handle more then 10,000 messages per second. Latencies can be of 3ms or less even on a Raspberry Pi 1 model b+.

SSL Security

Connectanum forces SSL encryption and supports the wamp-cra two-factor authentication as well as oAuth2 authentication.

It is also possible to use end-to-end encryption with the transparent payload feature.

Server Push and MVC like Controllers combined

The client provides an easy to use MVC like controller model to provide remote procedures as well as events to handle broad cast messages that belong to a subscribed topic.

The Connectanum client provides data transfer via PUB/SUB and distributed RPCs side by side.

Easy to scale and reliable business logic

The client scales by it's nature. Starting a second client is recognized by the router and will cause incoming request to be load balanced. This happens completely automatically.

The following load balancing algorithms are supported:

  • random (scaling) - the call is randomly forwarded to a connected client
  • round robin (scaling) - the call is forwarded to the next client in the registration stack
  • first (reliability) - only the first client is used to process the call. This is useful to compensate client crashes
  • last (reliability) - only the last client is used to process the call. This is useful to compensate client crashes
  • single (default) - scaling is not allowed. For a use with stateful business logic

Every call runs in a separate thread. This prevents the client to be blocked for coming up calls.

Modern and forward protocol design

The protocol was mainly developed by Tobias Oberstein and is available as open source on github or as specification draft on ietf.org.

All basic features and the following advanced features are supported by connetanum:

PUB/SUB
  • publisher_identification
  • subscriber_blackwhite_listing
  • publisher_exclusion
  • pattern_based_subscription
  • session_meta_api
  • payload_transparency
RPC
  • progressive_call_results
  • pattern_based_registration
  • shared_registration
  • caller_identification
  • session_meta_api
  • payload_transparency

Best support and open source for license owners

Feature or code enhancements are welcome to be requested. Our developers will schedule those requests to the closest possible future.

Nothing is impossible! Even connectors to other message protocols or authority handlers like oAuth2(already exist) or other are possible.

Transparency is most important for developers to understand what they are working with. We offer a complete open source account to our git repository and the ability to commit merge requests. There is no need to ask for support if you are familiar with netty and the protocol.

Low resource requirements

As mentioned in other parts of the page, the server can even be driven on a very low performing machine. There is no need to have high performing machines to route the messages.

The business logic may take most of the the server power. Easy distribution and scaling possibilities make it possible to simply plan the resource needs for each controller method or event of the business logic.