public inbox for nncp-devel@lists.cypherpunks.ru
Atom feed
From: John Goerzen <jgoerzen@complete•org>
To: Sergey Matveev <stargrave@stargrave•org>
Cc: nncp-devel@lists.cypherpunks.ru
Subject: Re: A few other features?
Date: Tue, 03 Aug 2021 15:22:10 -0500	[thread overview]
Message-ID: <87zgtywa6l.fsf@complete.org> (raw)
In-Reply-To: <YQkhRd/dZHWf+AkO@stargrave.org>


On Tue, Aug 03 2021, Sergey Matveev wrote:
> *** John Goerzen [2021-07-31 21:04]:
>>One is error handling.
>
> Yeah, that thing NNCP is completely lacking. Just logs and 
> retries
> forever until operator intervene with it. Definitely something 
> has
> to be done in that direction.
>
> I do not think that packet's ordering can be "solved" easily. If 
> we

I understand, and that's fine with me, and in fact the current 
retrying works for other situations as well.

>>One could request no notifications ever, notifications on
>>processing with any kind of result, or notifications only for 
>>errors.  These
>>notifications would be emailed back (and the address to send 
>>them to could
>>be specified).
>
> Also thought about that. But not sure about any kind of feedback 
> error
> channel, because of the complexity and possible metainformation 
> leakage
> (watching for the facts of feedbacked information sent back). 
> Currently
> I assume that NNCP networks are small enough and each time each 
> operator
> decides himself what to do, possibly manually sending email 
> about
> invalid/unexpected exec/whatever-packets.

It does send a message about certain things, right?  Such as files 
received?  Or is that different in your mind because that's all on 
the receiving end?  I suppose there could be a new packet type - 
"result" or some such - that wouldn't require a remote to be able 
to exec sendmail, and could be transformed into an email locally.


>
>>Secondly, reouting.  What if we supported, say, "partial source 
>>routing?"
>>A - B - C - D
>
> Exactly that use-case is already covered in 7.2.0 release. I 
> just tested
> it locally with [abcd] nodes to be sure. 
> http://www.nncpgo.org/Release-7_005f2_005f0.html

You know, I had thought that was the case too, and went back and 
looked at what had happened when I tried it.  Server in question 
was still on 7.1.1 *facepalm*.  Indeed it is doing that now.

That actually dramatically simplifies things.  Leaf nodes in a 
large "NNCPNet" wouldn't need to know much of any routing at all. 
Just set every node to go via a central hub and let the central 
hub figure it out.


> Passing as environment variable (something like NNCP_ARG1, 
> NNCP_ARG2
> ..., NNCP_ARGS=2) can complicate scripts forcing them to 
> probably unset
> those envvars before calling another command. Arguments are 
> "local" for

Very good point.

> just single command call. I think that using wrappers is just 
> some kind
> of necessary and completely ok thing to do. Someone probably 
> want to
> block the stdin entirely -- I do not think that NNCP should 
> cover all
> possible call-cases: flexible wrappers are for that.

Fair enough.  That makes sense.

- John

  reply	other threads:[~2021-08-03 20:23 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-01  2:04 A few other features? John Goerzen
2021-08-03 10:57 ` Sergey Matveev
2021-08-03 20:22   ` John Goerzen [this message]
2021-08-04  8:19     ` Sergey Matveev