public inbox for nncp-devel@lists.cypherpunks.ru
Atom feed

* autotoss bug
@ 2021-05-06 13:44 John Goerzen
  2021-05-30 11:42 ` Sergey Matveev
  0 siblings, 1 reply; 2+ messages in thread
From: John Goerzen @ 2021-05-06 13:44 UTC (permalink / raw)
  To: nncp-devel

Hi,

I started trying out -autotoss with nncp-call for the first time 
this week.  I experienced an issue with a set of data piped to 
nncp-exec; an incomplete set of data was sent to the process on 
the receiving side.

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.

I removed -autotoss from the command line, and after the calls 
with the remote eventually concluded, nncp-toss tossed the packet 
correctly (with full data).

The packet was being fed into a command that was able to detect 
the incomplete data and exited with an error code, permitting the 
retries that eventually succeeded.

I've never seen this behavior with regular nncp-toss.

Thanks,

- John

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: autotoss bug
  2021-05-06 13:44 autotoss bug John Goerzen
@ 2021-05-30 11:42 ` Sergey Matveev
  0 siblings, 0 replies; 2+ messages in thread
From: Sergey Matveev @ 2021-05-30 11:42 UTC (permalink / raw)
  To: nncp-devel

[-- 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 --]

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2021-05-30 11:42 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-05-06 13:44 autotoss bug John Goerzen
2021-05-30 11:42 ` Sergey Matveev