________________________________ From: Mario Loffredo <[email protected]>
> We opted for EoH to take advantage from being independent on TCP. I don't understand. Could you clarify? > We've explored every solution for managing HTTP sessions on a load-balancing > architecture, from sticky sessions to outsourcing session management to a > Redis cluster. The latter solution offers us maximum flexibility, > scalability, and fault tolerance and implement load balancing very > efficiently. Thanks for sharing. Are you relying on the "Cookie" request header to link HTTP requests with their EPP session? (This seems to be the suggestion in draft-ietf-regext-epp-https-02.) > My opinion is that WebSocket would not be the right solution, at least not as > efficient as traditional HTTP connections, since WebSocket connections > between client and server are stateful and long-lived via the load balancer. Could you give us some sense of the typical session duration and number of commands per session? > In this scenario, sticky sessions would be the only option to implement load > balancing for WebSocket, but based on our nearly twenty years of experience > and also widely described in literature, this wouldn't balance the load > efficiently and would require addressing some additional issues, such as > maintaining connection limits, keeping the service up during maintenance > operations, and handling a huge volume of requests. It seems like maintaining session limits is required in either design, and the number of requests is the same either way. However, I appreciate that if each session is bound to a connection, then a session cannot easily outlive its server instance. To determine whether this is acceptable, it would help to understand how long sessions normally last, and how much of a problem it is when a session is closed by the server. --Ben
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
