[prev in list] [next in list] [prev in thread] [next in thread] 

List:       inn-workers
Subject:    Re: tradspool tooken weirdness
From:       Julien_ÉLIE <julien () trigofacile ! com>
Date:       2024-01-18 18:41:55
Message-ID: 779d62e7-ddf7-4276-b388-ad38e14732c5 () trigofacile ! com
[Download RAW message or body]

Hi Christoph,

>> We discussed a MAXARTNUM capability to
>> achieve that in December 2022 in news.software.nntp:
>>
>>    <tnqm14$35bas$1@news.trigofacile.com>
>>    https://groups.google.com/g/news.software.nntp/c/4_KjHu9GlBg
> 
> Will read the entire discussion later. Personally, this idea gives me a
> bad feeling for introducing some complexity instead for just forcing the
> clients to deal it with. But possibly this has already been voiced and
> discussed.

The problem for "just forcing the clients" to deal with 64-bit article 
numbers, is that the NNTP protocol does not allow that.  Article numbers 
MUST be < 2^31.
So we can't just force clients to accept more, and let servers send such 
large numbers.
We would either need an update to RFC 3977 and define NNTP Version 3 
(with maybe other changes at the same time).  Servers would then either 
advertise Version 2 and/or 3, and behave differently depending on the 
client (which would probably have to advertise the version number it 
supports, by for instance announcing it as a keyword to CAPABILITIES, or 
any other way we would standardize in Version 3).  Well, that will be 
some work to do.
That's the reason why a simpler capability, compatible with RFC 3977, is 
proposed.  Unless the client advertises the maximum article number it 
supports, the server does not send such article numbers and cope with 
RFC 3977.  Note that Clive Feather, author of that RFC, already had that 
in mind (with the BIGNUM extension) but it was not explored more by the 
IETF working group, probably by lack of time or energy (there was 
already a lot of work to do with all the NNTP specifications at that time).


>>> On the other hand, there's the main lesson from y2k and upcoming
>>> y2038: Software will be used for way longer times and at way bigger
>>> scale than initially anticipated - therefore adapt early.
>>
>> As you're speaking about y2038, there's an open bug to support the upcoming
>> 64-bit time_t transition for 32-bit archs that some distributions plan to
>> do:
>>    https://github.com/InterNetNews/inn/issues/292
>>    https://wiki.debian.org/ReleaseGoals/64bit-time
>>
>> The CAF file header should be converted to use uint64_t instead of time_t
>> (as well as size_t and off_t).  Otherwise 32-bit system upgraded to 64-bit
>> time_t won't be able to retrieve old articles from a timecaf news spool.
> 
> Possibly this should indeed be done in a huge batch of fixing 32/64 bit
> issues. However, while tempting, my schedule is pretty full, so don't
> expect me to work on this any time soon, sorry.

No problem, you don't have to be sorry.  I totally understand!  (I too 
do not have unlimited time to work on INN.)  I was just pointing at that 
ticket, just in case :)

-- 
Julien ÉLIE

« – Tu parles ?
   – Tu parles ! » (Astérix)
-- 
inn-workers mailing list
inn-workers@lists.isc.org
https://lists.isc.org/mailman/listinfo/inn-workers

[prev in list] [next in list] [prev in thread] [next in thread]