Suggestion: TTL for expected users -- it just makes sense

Except if you own a Minecraft server or something to reserve your own slot, chances are you want your reserved slots to only last for ~10 seconds if you are doing any "matchmaking" style lobby.

The current style, onJoinedRoom, you have to remove yourself from expected users. However, what if you join, but disconnect? That reserved slot lingers. That means you have to add polling, and randomly clear the list every so often to clear these lingering expected users.

Even then, sometimes expected users still go weird. And if it just so happens that the polling cleared a reserved slot at the EXACT same time they reserved one, suddenly they aren't reserved at all.

Expected users TTL would just make sense. Minecraft server? Infinite. Matchmaking? 10 seconds or so. Then no need for polling, no need to find "stuck, lingering" expected users, it's intuitive, it works~

Comments

  • JohnTube
    JohnTube ✭✭✭✭✭
    Hi @xblade724,

    Thank you for your suggestion but I think things are not as easy as it seems.
    I think you are considering your own use case, from your current project.

    However, what if you join, but disconnect?
    If there are other actors joined, they detect that you are disconnected, if you are not allowed to rejoin with your UserId, then one of them should remove your UserId from Expected Users if it's there. If no one is there and EmptyRoomTTL > 0, next joining player should check Expected Users one by one and see if any element needs to be cleared depending on the game logic.

    And if it just so happens that the polling cleared a reserved slot at the EXACT same time they reserved one
    I recommend always settings player or room properties using CAS (Compare-And-Swap, Check-And-Set), this way you avoid this concurrent update issue.