https://livekit.io logo
Join Slack
Powered by
# helpdesk
  • d
    yes
  • w
    interesting, and is that used to store things like a users track?
  • w
    track(s)?
  • d
    it's the primary mapping we use on the server side
  • d
    it's an UUID
  • d
    when you refresh, it's likely that the websocket is now landing on a different node
  • d
    so something we have to figure out with this particular use case
  • w
    even though I'm only running one node?
  • s
    This message was deleted.
    m
    • 2
    • 1
  • w
    is there a reason livekit generates a UUID on the fly for each socket connection?
  • d
    that's what participant identity is for
  • d
    user provided unique id
  • d
    the server-assigned ID doesn't really need to change, so that's a good point
  • d
    it currently does because we use that id to coordinate signal connection as well, which could be on a different node as the RTC room
  • d
    I think I see the issue you are saying though.. is that if it changes in the same session, it could mess things up. I think there are def ways we could do to make that stable per room. the other related thing to improve is reconnection behavior.
  • w
    ya its also interesting to think about the socket closing but perhaps due to an error and if it reconnects
  • w
    does it make sense to draw a line and say: "if the socket closes, assume you must rejoin and republish" ?
  • w
    if so, I'd say purge everything related to that user + room and then its very straightforward to reconnect without any old data lingering on the server side (like zombie tracks)
  • w
    I'm going to spend more time on the server side to see if I can propose helpful additions to the disconnect flow
  • d
    that's be great! would appreciate your contributions there
  • s
    This message was deleted.
    w
    • 2
    • 1
  • d
    there could be cases where TCP connection is wonkey, but the underlying peerconnection stays connected
  • w
    I have noticed that the streams always stay on even after socket disconnects
  • s
    This message was deleted.
    d
    c
    • 3
    • 3
  • c
    At some point you might need to cut them off or switch to data channels for room communication instead of ws
  • s
    This message was deleted.
    👀 1
    ✅ 1
    d
    w
    • 3
    • 4
  • c
    Another panic
  • d
    this is single-node right? on 0.2.3?
  • d
    ok, pushed an update that re-uses participant id upon reconnect.. still a bunch of work to to ensure a smooth reconnect.
  • c
    sweet thanks
1...8910...91Latest