public inbox for nncp-devel@lists.cypherpunks.ru
Atom feed
From: Sergey Matveev <stargrave@stargrave•org>
To: nncp-devel@lists.cypherpunks.ru
Subject: Re: autotoss bug
Date: Sun, 30 May 2021 14:42:08 +0300	[thread overview]
Message-ID: <YLN6HPVAiGjD6jRw@stargrave.org> (raw)
In-Reply-To: <87fsz0ugcn.fsf@complete.org>

[-- Attachment #1: Type: text/plain, Size: 1965 bytes --]

Greetings!

*** John Goerzen [2021-05-06 08:44]:
>I had interrupted nncp-call with Ctrl-C at some point during this
>experimentation, and I also experienced some protocol-related hangups from
>each end, so I am theorizing that nncp-call attempted to autotoss an
>incomplete packet.

There is no specialized SIGINT (Ctrl-C) signal handlers, so any nncp-*
command will exit, breaking any possible background processes as is. No
waiting for toss finishing is done in that case.

But unfortunately I can not reproduce any misleading of unexpected
behaviour from -autotoss-ed nncp-call/caller. I experimented with very
slow toss exec task and small -onlinedeadline (lower than toss time) to
forcefully close the connection and finish the call, but anyway it
correctly leads to toss operation finish.

nncp.AutoToss() function is very simple and it literally uses an ordinary
Toss() that is used by nncp-toss:

    func (ctx *Ctx) AutoToss(nodeId, ...) (chan struct{}, chan bool) {
        finish := make(chan struct{})
        badCode := make(chan bool)
        go func() {
            bad := false
            for {
                select {
                case <-finish:
                    badCode <- bad
                    break
                default:
                }
                time.Sleep(time.Second)
                bad = !ctx.Toss(nodeId, ...) || bad
            }
        }()
        return finish, badCode
    }

And nncp-call/caller signals that it must be stopped and waits until the
completion:


    if *autoToss {
        autoTossFinish, autoTossBadCode = ctx.AutoToss(nodeId, ...)
    }
    badCode := !ctx.CallNode(...)
    if *autoToss {
        close(autoTossFinish)
        badCode = (<-autoTossBadCode) || badCode
    }

So currently I do not see where it can go wrong :-(

-- 
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

      reply	other threads:[~2021-05-30 11:42 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-06 13:44 autotoss bug John Goerzen
2021-05-30 11:42 ` Sergey Matveev [this message]