On 1/8/24 23:06, immibis wrote:
What format do NNTP peers usually take?
Peers usually push articles to each other.
Readers usually poll / pull articles from the server(s).
I see the "suck" tool can download import articles from any
public-access server without special negotiation. Does it put excess
load on the upstream server?
It depends.
I would never want to use suck for a full Usenet feed for anything other
than academic purposes.
Most people are using innfeed, right? innfeed peering is either IHAVE (chatty) or CHECK/TAKETHIS (streaming), is that right? Is there any
reason to use IHAVE except for compatibility with older servers?
I would have to refer to RFCs to know for sure, but these seem to be
ways to push articles to peers. Which is used when requires brushing up
on some RFCs.
I believe that innfeed is just one of the ways that INN supports to feed articles to a configured peer.
How's the connection managed? In other streaming protocols I'm more
familiar with (Redis, Apache Kafka) a receiving client would connect to
a server that has messages, state its last synchronization point and
then downloads messages from that point on.
My understanding is that INN (which uses innfeed) has knowledge of
articles that are queued to be sent to a peer and which queued articles
have been sent.
With this in mind, INN simply sends articles for desired newsgroups / distributions to wanting peers henceforth.
Peers don't have a way to say I want you to send me article <such and
such>. That's the domain of the reader to pull articles.
If the connection is interrupted, the messages still arrive upstream
and get stored until they're pulled by the receiver.
NNTP streaming doesn't have that feature, and I think innfeed is
designed so upstream servers try to push articles downstream, rather
than downstream ones pulling them, right?
My understanding of the mechanics may be flawed.
And failures to a separate spool for re-processing?
In a manner of speaking, sort of.
INN will periodically try to establish communications and will send (or
at least offer) spooled articles once communications is established.
Is there really no better way to authorize a connection than checking
the other side's IP address?
What is "better"? IP is quite convenient and works quite well between
static (or rarely changing) IPs.
You could use something like IPsec transport mode, or a full fledged VPN
to have much stronger cryptographic validation about the remote system.
But is such worth it for a news server?
Besides UUCP, is anyone using anything exotic?
I believe that some have TLS encryption in play.
I believe a very small number are using NNCP (?)
I would not be shocked to learn about IPsec / VPN being used.
(I should set up a server with a Kafka database and convince people to
peer directly to Kafka. Sounds !!fun!!)
Why?
IMHO that wouldn't be worth it.
What reason do you have to upset the apple cart? -- This is one of the reasons that I'm not interested in NNCP.
I'd be more inclined to use standard NNTP on a standard news server and
rely on the kernel to add IPsec transport mode encryption +
authentication to the traffic. News software doesn't have to be
involved and can rely on the kernel.
--
Grant. . . .
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)