private final long timeoutMillis;

    private final boolean permanent;

    private long startTime;

    private int status = ACTIVE;

    TimeoutTask(final TimeoutTarget timeoutTarget, final int timeout, final boolean permanent) {
        this.timeoutTarget = timeoutTarget;
        this.timeoutMillis = timeout * 1000L;
        this.permanent = permanent;
        this.startTime = System.currentTimeMillis();
    }

     * @param timeout the timeout duration
     * @param permanent whether the task is permanent
     * @return the {@link TimeoutTask}
     */
    public synchronized TimeoutTask addTimeoutTarget(final TimeoutTarget timeoutTarget, final int timeout, final boolean permanent) {
        final TimeoutTask task = new TimeoutTask(timeoutTarget, timeout, permanent);
        timeoutTaskList.addLast(task);
        start();

    /**
     * Determines if this address is set to be permanent.
     *
     * @param tc
     *            context to use
     * @return whether this address is permanent
     *
     * @throws UnknownHostException
     *             if the host cannot be resolved to find out.
     */
    boolean isPermanent(CIFSContext tc) throws UnknownHostException;

    /**

const val HTTP_PROCESSING = 102

/** `103 Early Hints (Early Hints - RFC 8297)` */
const val HTTP_EARLY_HINTS = 103

/** `307 Temporary Redirect` (HTTP/1.1 - RFC 7231)  */
const val HTTP_TEMP_REDIRECT = 307

/** `308 Permanent Redirect` (HTTP/1.1 - RFC 7538)  */
const val HTTP_PERM_REDIRECT = 308

/** `421 Misdirected Request` (HTTP/2 - RFC 7540)  */

linking directly to the master branch. This ensures that links reference a
specific point in time, rather than a document that may change over time.

See here for guidance on getting permanent links to files: https://help.github.com/en/articles/getting-permanent-links-to-files

Please use the following format for linking documentation:
- [KEP]: <link>
- [Usage]: <link>
- [Other doc]: <link>
-->
```docs

    /**
     * Error severity levels
     */
    public enum Severity {
        RECOVERABLE, // Can retry the operation
        TRANSIENT, // Temporary error, retry after delay
        PERMANENT, // Operation cannot succeed
        FATAL // Connection or session must be terminated
    }

    /**
     * Error categories
     */
    public enum Category {

Anyone asked to stop unacceptable behavior is expected to comply immediately. If an individual
engages in unacceptable behavior, the Square Code of Conduct committee may take any action they deem
appropriate, up to and including a permanent ban from all of Square spaces without warning.


[codeofconduct_at]: mailto:******@****.***
[twitter_coc]: https://github.com/twitter/code-of-conduct/blob/master/code-of-conduct.md

   * non-null, it should be reported to the user should all further attempts fail.
   *
   * The two values are independent: results can contain both (recoverable error), neither
   * (success), just an exception (permanent failure), or just a plan (non-exceptional retry).
   */
  data class ConnectResult(
    val plan: Plan,
    val nextPlan: Plan? = null,
    val throwable: Throwable? = null,
  ) {
    val isSuccess: Boolean

    * Normally, a token is set to expire after some time.
        * So, the user will have to log in again at some point later.
        * And if the token is stolen, the risk is less. It is not like a permanent key that will work forever (in most of the cases).
* The frontend stores that token temporarily somewhere.
* The user clicks in the frontend to go to another section of the frontend web app.

We can't rely on application threads to read data from the socket. Application threads are transient: sometimes they're reading and writing and sometimes they're off doing application-layer things. But the socket is permanent, and it needs constant attention: we dispatch all incoming frames so the connection is good-to-go when the application layer needs it.

So we have a dedicated thread for every socket that just reads frames and dispatches them.