Here is a thing I posted on Indy forums but also concerns Overbyte package

According to RFC-3977 article number is supposed to increase until it
reaches bounds of 31-bit value - 2,147,483,647 ( and while servers are not
allowed to send higher value by RFC, the RFC is still open to this
possibility and advises for newsreaders to have internal structures
prepared to hold higher values like unsigned 64 bit or so. In fact for some
high-volume newsgroups this number has been exceeded already ( and some newsreaders
have issues handling this. Some of the most popular news servers like
GigaNews are already sending high bound number in unsigned 64-bit format
and are recommending for newsreaders to implement this as well - - Note that this is
their recommendation but this is not necessary how other servers may handle
this - some may simply wrap counters to 32-bit value ignoring the high bits.

When the number reaches 32-bit limit odd things may happen in newsreaders -
they may stop accepting new articles. Some servers might (not sure) wrap
article numbers to reset the count. But most popular ones have chosen not
to do so but continue increasing the number and this is likely to happen
for others as well. In any case, using 64 bit integer for Article ID's is
better and safer at least until most news servers are either upgraded or
RFC is updated or it is decided what format to use.

OverbyteIcsNntpCli.pas uses 32-bit number and GetInteger function to
convert number to integer rather than StrToInt64. Additionally it uses -1
value as well which further limits the use of 32-bit range. Extending to
even 63-bit value (not even need for 64 bit unsigned) as 63 bit integer is
still a very very very very large number not likely to be reached anytime
soon even in alt.binaries.boneless.

How complicated a change to 64 bit article ID's is?
To unsubscribe or change your settings for TWSocket mailing list
please goto
Visit our website at

Reply via email to