Hello, curious about whether peering can be IPv6 these days
or basically whether INND is IPv6 aware/agnostic, or
whether INND and other cousins absolutely require IPv4 peers.
I was under the impression that IPv4 IP addresses are required,
yet I'd like to hear that IPv6 addresses are allowed.
Hello, curious about whether peering can be IPv6 these days
or basically whether INND is IPv6 aware/agnostic, or
whether INND and other cousins absolutely require IPv4 peers.
I was under the impression that IPv4 IP addresses are required,
yet I'd like to hear that IPv6 addresses are allowed.
Ross Finlayson <ross.a.finlayson@gmail.com> wrote:
Hello, curious about whether peering can be IPv6 these days
or basically whether INND is IPv6 aware/agnostic, or
whether INND and other cousins absolutely require IPv4 peers.
I was under the impression that IPv4 IP addresses are required,
yet I'd like to hear that IPv6 addresses are allowed.
IPv6 has been a first class citizen protocol in innd for more than two decades now.
Greetings
Marc
Hello, curious about whether peering can be IPv6 these days
or basically whether INND is IPv6 aware/agnostic, or
whether INND and other cousins absolutely require IPv4 peers.
I was under the impression that IPv4 IP addresses are required,
yet I'd like to hear that IPv6 addresses are allowed.
Peering and cleanfeed?
I'm under the impression that running "cleanfeed" is for whatever
reason part of running a Usenet server, that cleanfeed is a Perl
script with a bunch of regular expressions accepter/rejecter.
Is cleanfeed just convention, or if "required", is it just
a list of regexes?
Hello, curious about whether peering can be IPv6 these days
or basically whether INND is IPv6 aware/agnostic, or
whether INND and other cousins absolutely require IPv4 peers.
I was under the impression that IPv4 IP addresses are required,
yet I'd like to hear that IPv6 addresses are allowed.
Hello, curious about whether peering can be IPv6 these days or basically whether INND is IPv6 aware/agnostic, or whether INND and other cousins absolutely require IPv4 peers.
I was under the impression that IPv4 IP addresses are required,
yet I'd like to hear that IPv6 addresses are allowed.
On Mon, 18 May 2026 09:20:56 -0700, Ross Finlayson wrote:
Hello, curious about whether peering can be IPv6 these days or basically
whether INND is IPv6 aware/agnostic, or whether INND and other cousins
absolutely require IPv4 peers.
I was under the impression that IPv4 IP addresses are required,
yet I'd like to hear that IPv6 addresses are allowed.
6 is fanboism hype....
On April 1st each year, (and yes when I started doing this, it was to
prove 6 was a joke, so A.F.D seemed very appropriate day :P ) I run a previous 28 day test on our (commercial) website, and on our MX's (all
front ends logs combined into one for single usable data point)
the percentage of IPv6 this year...
WWW 0.002% whats that... 1 in 50000?
MX 0.046% and 1 in 2000 -ish?
Contrary to some countries requirements, AU does not require logging DNS,
so we don't and can't provide stats there, in checking our FTP mirror
server, there are no ipv6 hits.
It's nice to offer both, sure, but these results show me there is no
effort required to make news play nice with ipv6 at this time.
the percentage of IPv6 this year...
WWW 0.002% whats that... 1 in 50000?
This is rather interesting. Which people use your service?
Are there heavy users from IPv4 only networks?
FTP is almost dead, sadly.
It's nice to offer both, sure, but these results show me there is no
effort required to make news play nice with ipv6 at this time.
Are there cases where NNTP does not work with IPv6?
INN supports that, IIRC this is the last NNTP server that is actively developed.
Various INN sites have IPv6 enabled.
we stuck with DNews as it is extremely fast, very very light with system resource usage, and its spool method just works with auto-healing in case
of errors in self checks, from showing one of the smaller "buckets" as
DNews calls them, to Julien some time ago, he thinks it was closest to
INNs CNFS buffers, but DNews creates new bucket files on the fly when it needs to, unlike INN where one must manually create them when needed,
DNews is more or less set and forget, hence why I've stayed with it, did
look at INN back when we had that discussion but nothing we did was going
to reduce the time it was going to take to import the articles, it was
going to make many MONTHS, so we shelved that idea since we have a very efficient daemon at present despite not being supported in 20 years.
I know Jesse's little project is taking him a long time, I don't have
that much patience :)
Some people recommend increasing the number of concurrent connections from the
source, but I found this hampers performance when INN is under load. I got the
best performance by increasing icdsynccount and using a single innxmit process
on the sending side.
disk I/O and read/write speed), because I'm trying SQLite too but I'm >getting excellent performance on small to medium-sized group messages >(<500.000 posts), but on large groups, performance is terrible if not >disastrous (>1.000.000 posts).
Sometimes the performance of SQLite can be improved by
- adding indexes on fields frequently used in WHERE, JOIN, or
ORDER BY clauses (but not adding indexes on other fields)
- partial indexes can speed up certain queries
- PRAGMAS for use directly after opening the connection:
- PRAGMA journal_mode = WAL; (for simultaneous reads and writes)
- PRAGMA synchronous = NORMAL; (to reduce synch frequency)
- PRAGMA cache_size = -200000; (~ 200 MB instead of 2)
- PRAGMA temp_store = MEMORY; (forces tmp tables to memory)
- keeping huge BLOBS in a separate table (like, a 1-to-1 table
for bodies)
- VACUUMing a database creates a copy of it, and thus requires
additional disk space
However, I only take these ideas from a text and have not tried
them out myself.
Il 28/05/2026 14:19, Jesse Rehmer ha scritto:
Some people recommend increasing the number of concurrent connections
from the
source, but I found this hampers performance when INN is under load. I
got the
best performance by increasing icdsynccount and using a single innxmit
process
on the sending side.
I'm currently writing software that will interface with INN2 (and other software) and I'm seriously considering using LMDB/MDBX. I'm testing it right now and has many advantages and very few disadvantages (especially disk I/O and read/write speed), because I'm trying SQLite too but I'm getting excellent performance on small to medium-sized group messages (<500.000 posts), but on large groups, performance is terrible if not disastrous (>1.000.000 posts).
I wonder if this option has ever been considered in place of ovsqlite
with cnfs. I think it would solve a lot of the problems INN currently suffers from.
Just 4 info:
XOVER on SQlite on a group with 50.000.000 post = 3.475s
XOVER on LMDB on same group = 0.364s
XOVER on MDBX on same group = 0.198s
HW: AMD Epyc 9745, 256GB RAM on SAS hd.
MDBX it's more faster, but have more disadvantages than LMDB (more
secure on disaster recovery)
Sincerely
| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 74 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 45:37:40 |
| Calls: | 1,100 |
| Files: | 1,339 |
| Messages: | 275,479 |