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