[erlang-questions] [ANN] Iris v0.3.0 and Erlang binding v1.0.0

Lee Sylvester <>
Mon Aug 11 18:39:49 CEST 2014


I missed some questions :-)

3. “When” a node is temporarily partitioned on the network, does it try to reconnect?  If so, how often and for how long?

4. When sending a message to a cluster, how is the node selected?  I’m assuming round robin.  However, it would be good to be able to supply a callback for a node so that it can supply a value.  This value could then be compared against its peers and the lowest value selected. For instance, I have a messaging transport cluster which can cater for a given number of clients.  Currently, I ping all available nodes and they readily supply a count value of their connected peers.  I can then educatedly choose the lowest value to always provide the least loaded node.  This is a simple task, but one which would work well in this scenario, especially when tasks may take seconds or hours (video encoding).

Cheers,
Lee



On 11 Aug 2014, at 17:30, Lee Sylvester <> wrote:

> Hi Péter,
> 
> This looks great.  I have a couple of questions, though.  
> 
> 1. Is it possible to cluster brokers?  Having a single broker would be a single point of failure.  It would be better to cluster the brokers; or maybe even have one broker per physical VM.
> 
> 2. What messaging protocol does this use?
> 
> Thanks,
> Lee
> 
> 
> On 11 Aug 2014, at 14:13, Péter Szilágyi <> wrote:
> 
>> Hi all,
>> 
>>   For a few years now I've been researching and working on a decentralized cloud messaging system called Iris. My goal with it was to bring the simplicity of cloud computing to the application layer, with the motto that if renting a batch of VMs can be done in one line of code, then assembling them into a communicating distributed system should be doable with another line. I'm proud to say, that Iris was voted as one of the most innovative open source projects related to scalability and devops, being nominated as a finalist for the dotScale prize.
>> 
>>   If I had to summarize the project in one sentence, it would be: "A completely decentralized messaging solution for simplifying the design and implementation of cloud services, featuring zero-configuration (i.e. start it up and it will do its magic), semantic addressing (i.e. application use textual names to address each other), clusters as units (i.e. automatic load balancing between apps of the same name) and perfect secrecy (i.e. all network traffic is encrypted)". And just to complete the above description, it is fast and language agnostic ;)
>> 
>>   Today marked the release of version v0.3.0 of the Iris core, and with it I'm very proud to release the first stable version of the Erlang API too, v1.0.0! The API follows the OTP design patterns, and specifically that of the gen_server, but takes it way beyond in capabilities :D Just as a teaser, this is how you can attach a micro-service instance to Iris through Erlang, which will then completely automatically integrate with other nodes and services written it arbitrary languages, and be able to communicate with them completely decentralized and completely secure!
>> 
>> -behaviour(iris_server).
>> -export([init/2, handle_broadcast/2, handle_request/3, handle_tunnel/2,
>>     handle_drop/2, terminate/2]).
>> 
>> % Implement all the methods defined by iris_server.
>> init(Conn, your_init_args) -> {ok, your_state}.
>> terminate(Reason, State)   -> ok.
>> 
>> handle_broadcast(Message, State)     -> {noreply, State}.
>> handle_request(Request, From, State) -> {reply, Request, State}.
>> handle_tunnel(Tunnel, State)         -> {noreply, State}.
>> handle_drop(Reason, State)           -> {stop, Reason, State}.
>> 
>> main() ->
>>     % Register a new service to the relay
>>     {ok, Server} = iris_server:start(55555, "cluster name", ?MODULE, your_init_args),
>> 
>>     % Unregister the service
>>     ok = iris_server:stop(Server).
>> 
>>   As you can see above, you can have broadcasts (received by *all* members of a particular micro-service cluster (the name specified during registration above), requests (load balanced between *all* members of a particular cluster), tunnels for ordered and throttled stream oriented communication between two nodes, and pub/sub (API through a different module). No networking code involved, period.
>> 
>>   Since seeing is believing, I invite anyone interested to look at the online Erlang playground, which is a short introductory presentation of Iris and its Erlang binding, walking over each communication primitive with modifiable and executable code segments. Should it wet your appetites, further infos can be found in the Erlang quick-start guide. Of course, the most valuable source of information is the Iris website itself, containing pre-built binaries and other language bindings on the downloads section, recordings from live presentations on the talks section (FOSDEM, dotScale), a work-in-progress guide called The book of Iris and last but not least, some research papers for the academically inclined. And if you really want to dive deep, all source code is available on GitHub (dev docs at edoc).
>> 
>>   Hope you like it, and if you have any questions or feedback, I'm more than happy to answer/react :)
>> 
>> Cheers,
>>   Peter
>> 
>> PS: If you're interested enough, you are welcome into the Iris community at the project-iris mailing list or @iriscmf on Twitter.
>> _______________________________________________
>> erlang-questions mailing list
>> 
>> http://erlang.org/mailman/listinfo/erlang-questions
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140811/762011b7/attachment.html>


More information about the erlang-questions mailing list