Verify behavior description of egress traffic about sbulb HOT 7 CLOSED

My feeling is, that the drop in the second cause trouble. Doesn't that depend on the server sending it? If it's the "associated one", then the packet should pass as in the third.

I read this again and you're right.

I tried again :

For egress traffic :

• we search if we have an clientip:port/realserverip association.
• if yes and packet comes from the associated real server , we modify source address (source NAT) replacing real server address by the virtual server ip address.
• if yes and packet comes from "not associated" real server, we drop the packet
• if no, we create a new association using the source IP address(real server IP address) and modifying source address(source NAT) by the virtual server ip address.

Is it better ?

from sbulb.

Yes!

from sbulb.

This is fixed in master. Thx @boaks for reporting this. 🙏

from sbulb.

@boaks, not directly linked to this issue.

But I believe that you are working on making ConnectionID more used.
Is this project something which could interested you ?
(The code was rewrited a lot and unit test was added in : #34)
I think it could totally make sense to add CID support (#9) to it.

I have a vague memory that CID in a cluster could be useful for hono too ? Am I right ?

from sbulb.

Is this project something which could interested you ?

I think, in the future, yes. For now my interest was to collect information around "CoAP/DTLS load-balancing" and current implementations of that.

But I believe that you are working on making ConnectionID more used.

Currently I work on a solution, where Californium/Scandium forward the CID messages on their own.
wip_dtls_cid_cluster.
My first results are promising (performance penalty of "java message forwarding" 15-20%) and it's easy and flexible to use. It doesn't require additional components. My intention is, to gain more experience.

I think it could totally make sense to add CID support (#9) to it.

My feeling is, that, if the penalty is only 20% but no additional components are required, then that's good enough to learn, if it pays-off. So, I would postpone that for now. May be next spring will be the right time.

Let me add, your current implementation considers the address:ports to be rather stable. Though I guess, adding a balancing based on "Source Hashing" may easier generate benefit for now.

from sbulb.

I think, in the future, yes. For now my interest was to collect information around "CoAP/DTLS load-balancing" and current implementations of that.

Do not hesitate to share what you find :)
Our needs was strong stickiness and server-initiated, we found nothing about that.

Though I guess, adding a balancing based on "Source Hashing" may easier generate benefit for now.

You mean something like this : https://www.haproxy.com/blog/client-ip-persistence-or-source-ip-hash-load-balancing/

Allowing kind of stateless load balancing ?
I will think about this 🤔.
Issue could be to keep the stickiness specially when you add or remove server dynamically.

from sbulb.

Issue could be to keep the stickiness specially when you add or remove server dynamically.

My idea was more the additional option to use it. If it comes with as "static cluster" instead of a "elastic cluster", then it seems to be the decision of the user to chose, what fits best.

from sbulb.