Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Connection loss, reconnects (and CAP theorem) #695

Open
mariohock opened this issue May 15, 2021 · 2 comments
Open

Connection loss, reconnects (and CAP theorem) #695

mariohock opened this issue May 15, 2021 · 2 comments

Comments

@mariohock
Copy link

Hi, I'm thinking about realizing a shopping list app with Flexx. It should support live syncing between the "shoppers" (i.e., users) when there is Internet connection. But it should continue to work if there is no signal in the store.

Currently, as soon as the web socket connection is broken, the Flexx page is cleared and only shows "Lost connection with server". This means I can no longer see my shopping list at all, which would be kind of inconvenient. It seems reasonable simple to disable this behaviour in app/_clientcore.py. But what happens when the connection is back? Is it possible (reasonable to implement a way) to establish a new web socket connection?

Finally the state in the browser (JS part) needs to be synced with the server (Python part) again. E.g., tell the server that I checked-off some items in the meantime. Due to the CAP theorem (https://en.wikipedia.org/wiki/CAP_theorem) it is never trivial to solve this, which means there can't just be a simple built-in solution, since there is always a trade-off involved. This means the app developer would need some freedom to re-establish a consistent state.

A simpler solution in my case would be not to re-sync the state but at least give the JS part the possibility sent its state back to server (i.e., the Python part), let it process the data and then reload the page.

The CAP theorem states that you can never have "consistency", "availability", and "partition tolerance" altogether. You always have to pick one or two. Flexx apparently chose the property "consistency" and sacrifices "availability" and "partition tolerance". In my use case "availability" and "partition tolerance" are crucial while "consistency" could be sacrificed. Is there some interest in the community to give the app developers some more freedom to choose between C, A, and P or is Flexx just the wrong system for this use case?

@Konubinix
Copy link
Contributor

Konubinix commented May 16, 2021 via email

@mariohock
Copy link
Author

mariohock commented May 16, 2021

Thanks for your input, I notice that "partition tolerance" is also relevant for others. :-)

The CAP theorem is proven for "distributed data stores", however, I think it's safe to say that it applys to networking in general. But of course, in some cases the trade-offs are so straight forward that one would not need a theorem to get it. But, as you say, the CAP theorem makes it clear, that the desired behavior in a partition scenario is quite app specific. This means, the app developers need some tools to deal with it.

In your case, I think, there is no potential for conflicting state. This means it should be quite easy to get the state of your app up-to-date, if flexx had the ability to recover from connection loss, i.e., could establish a new websocket connection.

Just for demonstration: Your case would be much harder if there were two tablets and if users could make active inputs (like change the background color or something). If different background colors were chosen on the two tablets during the night, flexx could not resolve this conflicting state automatically. But you could write some app logic to solve it that suits your use case (e.g., just pick one since it's not a critical feature anyway).

I imagine something like that the JS part and the python part keep running during connection loss but any cross-boundary action throws a "catchable" exception. If I catch it, I have to deal with consistency/availability. If I don't catch it we could still display "connection lost". Also both sides should be notified if connection is lost/re-established.

Is it technically possible to just open a new websocket connection when the initial one is broken? Or is there too much going on in the background that would break in this case?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants