SSL

[chartera]

Is communication over SSL/TLS possible (for Multi-Datacenter scenario), to seamlessly encrypt the message traffic?

Does the following configuration work?:

{riak_core, [ % ... {handoff_ssl_options, [ {certfile, "/full/path/to/site1-cert.pem"}, {keyfile, "/full/path/to/site1-key.pem"}]} % ... ]}

Best regards

[albsch]

SSL support was removed in this commit.

[albsch]

Can we add this somehow to riak_core_lite_util @marianoguerra ?

[chartera]

SSL support was removed in this commit.

To fork and to undo looks like easy at first for me ... but is there any special reason for removing?

[albsch]

Simplifying and reducing dependencies to get a working minimal version.

[ghost]

riak_core_lite is not targeted at multi-datacentre replication. I don't know why that stanza was ever configured in the riak_core application. riak_repl is the application which actually performs multi-datacentre replication. The configuration should be in riak_repl. The intent of this project to create a simplified, working, well-understood, riak-core which can be embedded in whatever application people care to embed it within. multi-datacentre replication is, as far as I understand, out of scope for the time being. I would imagine a separate erlang application will be responsible for that kind of work.

[chartera]

Erlang has out of the box secure distribution over tls with the appropriate settings. The problem was the handoff mechanism of riak_core_lite, which opens a new unsecured tcp connection instead of using the Erlang node connection or create a new secure tcp connection. I've solved the problem for my use case, just undo commit.

[ghost]

Erlang has out of the box secure distribution over tls with the appropriate settings. The problem was the handoff mechanism of riak_core_lite, which opens a new unsecured tcp connection instead of using the Erlang node connection or create a new secure tcp connection. I've solved the problem for my use case, just undo commit.

Just to be clear - multi-data-centre replication and handoff are two different things (ex basho here).
The reason riak used a custom tcp connection rather than distributed erlang was because of head of line blocking of the inter-node communications when handing off a large amount of data.
Thanks for clarifying more context.

[albsch]

The reason riak used a custom tcp connection rather than distributed erlang was because of head of line blocking of the inter-node communications when handing off a large amount of data.

This is fixed in OTP22, so we could change the communication to distributed Erlang, right?

[ghost]

The reason riak used a custom tcp connection rather than distributed erlang was because of head of line blocking of the inter-node communications when handing off a large amount of data.

This is fixed in OTP22, so we could change the communication to distributed Erlang, right?

http://blog.erlang.org/OTP-22-Highlights/#fragmented-distribution-messages

Fragmenting very large messages helps, yes. But there is also the issue of one receiving mailbox per node - see this section of the gen_rpc README for more explanation...

[chartera]

My understanding is that by sharding the data like a broker to different processes (last sentence of Rationale) maybe bypass the issue of gen_rpc ... ? This could become very complex ... Im happy with the solution we have now ... Thank you guys :)