Duet3D Logo Duet3D
    • Tags
    • Documentation
    • Order
    • Register
    • Login

    http /machine/connect session timeout

    Scheduled Pinned Locked Moved Solved
    Third-party software
    2
    6
    153
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • stuartofmtundefined
      stuartofmt
      last edited by

      I'm using 3.6.0 rc.2 SBC on bookworm.

      TLDR; Session timeout of 8 seconds seems too short. More-or-less forcing an explicit reconnect before any other call (to be safe) seems wasteful.

      Is there a better way? Am I misinterpreting?

      Some plugin code (which I would have sworn before was working) has stopped.
      Essentially, this is what is happening:

      1. I use /machine/connect to connect and get a session key
      2. Some time later (more than 8 seconds) I try to use /machine/code to send a M291 Message however it errors out with code 401

      Looking in the journal I can see the session key being expired

      Apr 26 21:21:01 srsender DuetWebServer[699]: Microsoft.AspNetCore.Hosting.Diagnostics[1] Request starting HTTP/1.1 GET http://192.168.10.140/machine/connect?password=reprap - - -
      Apr 26 21:21:01 srsender DuetWebServer[699]: DuetWebServer.Singletons.SessionStorage[0] Session dbd8f686859c46a188512afad6e3a8cd added (readWrite)
      <snip>
      Apr 26 21:21:09 srsender DuetWebServer[699]: DuetWebServer.Singletons.SessionStorage[0] Session dbd8f686859c46a188512afad6e3a8cd expired
      

      This document https://github.com/Duet3D/DuetSoftwareFramework/wiki/REST-API
      States:
      The resulting session is maintained at least 8 seconds but it may last as long as

      a WebSocket is open
      a long-running HTTP request is being processed (code, upload, and package requests) When the session has expired, HTTP code 403 is returned by other requests.

      An implication of this is that any application that doesnot interact with DSF needs to more-or-less, reconnect every 8 seconds. This seems wasteful.

      Compare this to rr_connect which has a session timeout of 8000 seconds.

      stuartofmtundefined chrishammundefined 3 Replies Last reply Reply Quote 0
      • stuartofmtundefined
        stuartofmt @stuartofmt
        last edited by stuartofmt

        A small update: I did some tests with /machine/connect and /rr_connect Not sure if this behavior is intended or not.

        The /machine/connect API has a session timeout of ~ 8 seconds independent of whether a password is required/used or not.

        The /rr_connect API appears to have an 8000 second timeout when no password is required but has an 8 second password when a password is required.
        Also /rr_connect?sessionKey=yes does not provide a sessionKey (at least when called from a browser).

        EDIT: Programatically using /rr_connect?sessionkey=yes&password=<password if used> returns (i.e. no session key also).

        {"apiLevel":1,"err":0,"isEmulated":true,"sessionTimeout":8000,"boardType":"duet5lcunknown"}
        
        1 Reply Last reply Reply Quote 0
        • chrishammundefined
          chrishamm administrators @stuartofmt
          last edited by

          @stuartofmt If you do not have a password set and don't specify a session key, then there should be no need to use one. For the same reason requests like /machine/model work from a plain browser tab. If you have a password set, there is no alternative, though. The reference implementations all depend on those keys because we cannot assume users never specify passwords.

          In addition to that, the session timeout is configurable via /opt/dsf/conf/http.json - see SessionTimeout in there.

          Duet software engineer

          stuartofmtundefined 1 Reply Last reply Reply Quote 0
          • chrishammundefined
            chrishamm administrators @stuartofmt
            last edited by

            @stuartofmt said in http /machine/connect session timeout:

            Compare this to rr_connect which has a session timeout of 8000 seconds.

            I guess you mean ms here - that's what the value indicates.

            Duet software engineer

            stuartofmtundefined 1 Reply Last reply Reply Quote 0
            • stuartofmtundefined
              stuartofmt @chrishamm
              last edited by

              @chrishamm said in http /machine/connect session timeout:

              @stuartofmt said in http /machine/connect session timeout:

              Compare this to rr_connect which has a session timeout of 8000 seconds.

              I guess you mean ms here - that's what the value indicates.

              I misinterpreted that as seconds because of the behavior when I did not have a password set..

              1 Reply Last reply Reply Quote 0
              • stuartofmtundefined
                stuartofmt @chrishamm
                last edited by

                @chrishamm said in http /machine/connect session timeout:

                @stuartofmt ..... If you have a password set, there is no alternative, though. .....

                In addition to that, the session timeout is configurable via /opt/dsf/conf/http.json - see SessionTimeout in there.

                As a practical matter then, if a password is set and when the time between calls is not known: It looks like every call ought to disconnect, connect, make the desired call. An alternative would be to keep track of how long its been since the last connect call and if >= 8 seconds: connect , make the desired call

                I'd be loath to "hijak" a system wide variable for the sake of a plugin 🙂

                Thanks for the clarity. The documentation does not make it entirely clear that there is a different behavior between the no-password vs password scenario.

                1 Reply Last reply Reply Quote 0
                • stuartofmtundefined stuartofmt marked this topic as a question
                • stuartofmtundefined stuartofmt has marked this topic as solved
                • First post
                  Last post
                Unless otherwise noted, all forum content is licensed under CC-BY-SA