Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [leshan-dev] Leshan cluster
Hi Daniel,
yes the first idea is to add and remove nodes to the cluster for scaling up/down, and doing blue/green deployment for new version (a bit like http://martinfowler.com/bliki/BlueGreenDeployment.html).

It's not providing resuming request lost while a node crash.

When you remove a node, you need to remove it from the load balancer list of active node so no new connections are sent to this node. Then wait something like 5 minutes for being sure all the current coap transaction processing are done and then kill the machine.

If the node crash it's not resuming the CoAP transaction on another node. It's probably doable with some effort, but it's probably mean serializing more Californium state in Redis and making more Californium changes and yes probably it have some performance impact.


I don't think storing only the token id can solve the problem. how do you resume retransmission on a new node in case the response sent by the client was lost and the server need to retransmit the request?

--
Julien Vermillard

On Mon, May 2, 2016 at 5:29 PM, Maier Daniel (INST/ECS4) <Daniel.Maier@xxxxxxxxxxxx> wrote:

Hi,

 

I have read https://github.com/eclipse/leshan/wiki/Cluster.

 

As I understand, the plan is to store tokenIds only for observe requests and not for requests like read, write etc. This would have the consequence that if one cluster node goes down, all request that are still in progress on this cluster node will be lost. The user (some application) never notices that his request was lost because he will not be notified in some way (Well, this would be also not be possible with the current callback design even if we would store the request). Is this intended as a tradeoff between performance and reliability? Is the user responsible to retry requests that got no response for a while himself?

 

I think it would be useful to store also tokenIds of other requests, i.e. another cluster node can handle the response even if the request issuer went down (We still have the problem that also another node needs to take over the responsibility for the retries). But to implement this we would need another design of the callbacks for requests in order to propagate the response to a listener on another cluster node.

 

What do you think, is this approach over the top?

 

Thanks a lot

Daniel

 

Von: leshan-dev-bounces@xxxxxxxxxxx [mailto:leshan-dev-bounces@xxxxxxxxxxx] Im Auftrag von Julien Vermillard
Gesendet: Montag, 15. Februar 2016 14:59
An: leshan developer discussions
Betreff: Re: [leshan-dev] Leshan cluster

 

Hi Paul,

Neither HA-proxy, nor ningx  support UDP or CoAP.

This could solve part of scalability problem by offloading the DTLS processing of the leshan server.
This could be a good idea, but now the biggest challenge we have is the token matching for observe and this solution won't have an impact on it :(

In a second step that could be interesting, for example to use a more CPU optimised AES/TLS implementation like the one in OpenSSL and built a CoAP reverse proxy to use a load-balancer.
Now since we want both way authentication using per endpoint credentials (PSK and RPK) we need to pass the result of the authentication back to the backend server.
In HTTP world this is done by adding a HTTP header, we could imagine sending it as a CoAP option. So we need to build a CoAP reverse proxy able to change the CoAP messages.

But I see it more as a performance/infrastructure optimisation.


--
Julien Vermillard

 

On Fri, Feb 12, 2016 at 6:28 PM, <szego@xxxxxx> wrote:

 

Regarding security and the proposed network infrastructure, has anyone considered how we might support DTLS termination at the load-balancer layer? I’m thinking along the lines of how HTTP load balancers can handle TLS termination (e.g. HAProxy, nginx) out in the DMZ.

 

I’m keen to see that whatever we arrive at doesn’t preclude this.

 

Regards, Paul.

 

On 11 Feb 2016, at 7:10 AM, Julien Vermillard <jvermillard@xxxxxxxxx> wrote:

 

Hi,
Following the discussion we had during the last meeting:
https://github.com/eclipse/leshan/wiki/Cluster

Please feel free to comment/edit

--
Julien Vermillard

_______________________________________________
leshan-dev mailing list
leshan-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/leshan-dev

 


_______________________________________________
leshan-dev mailing list
leshan-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/leshan-dev

 


_______________________________________________
leshan-dev mailing list
leshan-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/leshan-dev


Back to the top