search

spring / uberserver

uberserver, a matchmaking/chat lobby server for the spring rts project
https://springrts.com/wiki/Uberserver
Other
33 stars 38 forks source link

allow a fresh login to replace an old client #281

Closed silentwings closed 4 years ago

silentwings commented 6 years ago

instead of https://github.com/spring/uberserver/blob/master/protocol/Protocol.py#L903, if the pw is correct then disconnect the old session and allow a fresh login

requested by ThinkSome - use case is people with unstable connections, who are cut off by their isp and then have to wait for their old login to timeout before they can reconnect, also seems a bit more modern to me

MasterBel2 commented 5 years ago

How long are the clients having to wait for a fresh login?

silentwings commented 4 years ago

Won't fix - not really necessary and would lead to complications in keeping a consistent internal state.

MasterBel2 commented 4 years ago

Easiest way to avoid complications (as I can see) is to replace this line with self.in_EXIT(self._root.clients.<fillintheblank>, "Logged in from other location") and remove the return statement.

I'm not quite well-versed enough in Python to know exactly how this would work, so even if it doesn't, I'd love to know what the code would actually look like

silentwings commented 4 years ago

Regardless of syntax, that would cause multiple inconsistencies in the server state due to changing of session_id & other properties.

MasterBel2 commented 4 years ago

I don't see how it'd change sessionID. Wouldn't it effectively simulate the person logging out from one location, then logging in from the other?

silentwings commented 4 years ago

Oh, you want to kick them out - that results in them leaving all battles & channels, and losing all other non-db parts of their login state, which is also not good.

The session id would change, because of the new socket connection, but since you'd kick them out that part wouldn't actually break the server, it would just be irritating for the client and all others who depended on their presence/state.

A "proper" solution requires removing the old session silently, forcibly copying a careful selection of its non-db properties into the new session, then search+update every single part of the servers internal state (i.e. battles, channels, bridges...) which contained their old session id & perhaps other non-db properties of the session. It's not worth it.

MasterBel2 commented 4 years ago

The "proper" solution you have in mind would also involve a large-scale re-architect of lobbies too, I would imagine. But what's the target use case for this?

use case is people with unstable connections, who are cut off by their isp and then have to wait for their old login to timeout before they can reconnect

As far as I'm aware, people usually discover they they have to reconnect because their lobbies disconnect, I.e. according to user experience, they have been logged out. Am I incorrect?

it would just be irritating for the client and any others who depended on their presence/state.

It's more irritating to not have this solved. Please don't discount a perfectly valid 5-second fix because there exists a more "perfect" solution that is too much effort to implement instead.

For example – when Mac (similar to windows in this respect) has a kernel panic, they're not able to software-restart the computer because they can't trust the computer's current state. So they display a screen asking the user to restart the computer. They don't give up and say it's too hard and do nothing.

silentwings commented 4 years ago

The "proper" solution you have in mind would also involve a large-scale re-architect of lobbies too, I would imagine

No. I have no idea where you got that from.

Please don't discount a perfectly valid 5-second fix because there exists a more "perfect" solution that is too much effort to implement instead.

If you come up with one, but your suggestion above is frankly not good enough. As said, I don't see much scope for half-hearted efforts here but PRs will be reviewed if made.

people usually discover they they have to reconnect because their lobbies disconnect,

If lobbies do that whilst still online (which I have never heard of) you should presumably report a bug in your lobby.

This: use case is people with unstable connections, who are cut off by their isp

For example – when Mac (similar to windows in this respect) has a kernel panic, they're not able to software-restart the computer because they can't trust the computer's current state. So they display a screen asking the user to restart the computer.

This is amusing but in 2020 you can get an OS that works properly instead.

(Also, no sane OS does that, they shut down the OS without asking the user first, to avoid any further damage whilst user is busy staring out of window, and then they might offer to restart, although non-ancient hardware can just do it without user help.)

Aside from motivational speech afaics this has literally no connection to the ticket.

MasterBel2 commented 4 years ago

Ok, never mind.