On 02/04/2001 13:05, "Paul Berkowitz" <[EMAIL PROTECTED]> wrote:
> I've been checking. Although occasionally command-L presents 1 or 2 brand
> new headers from the server that have just been uploaded there, 95% of the
> time nothing new arrives. When I click "More", I get the correct number of
> headers (2 or 3 usually) from about 2 months ago: December 9 and 10, 2000,
> appeared today. Since I have previously "Marked All as Read", those headers
> should not be showing as Unread and annoying me this way, should they? If
> this isn't a bug (albeit a different one than i first thought), what is it?
Would you accept "A potential annoyance in the underlying infrastructure of
NNTP and the various transport agents implementing NNTP"?
On 02/04/2001 14:11, "Paul Berkowitz" <[EMAIL PROTECTED]> wrote:
> Well, that could be. How do you think it would happen? Is it the server
> rather than the news client that keeps track of "Read" and "Unread" for
> everyone? That seems unlikely. I know that POP mail servers use something
> called POPpers, which all work differently (one of my mail servers marks
> "Read" correctly when I've downloaded once from that account and will obey a
> Rule i have in place to mark as read when I download the same messages from
> my other computer, but my regular ISP's mail server can't do this.) I don't
> see how a news server could keep track of all its thousands and thousands of
> users.
>
> Does anyone know how this works?
I could tell you, but then I'd have to kill you.
Oh...maybe I'll just mentally maim you...
The news client software is responsible for tracking read/unread
information. It generally works something like this.
1) The client connects to the server and requests information about a
certain group.
2) The server responds, telling the client an ID number (a number that only
has meaning in the context of this particular server and this particular
newsgroup...and it's most definitely *NOT* the message ID which actually
uniquely identifies each news message and would be far too sensical) for the
first message that it has (serverFirst) and the last message that it has
(serverLast)...and perhaps the number of messages that the server has stored
for that group (serverCount - which one might naively expect to have some
relationship to the value (serverLast - serverFirst)...but one would most
often be wrong).
3) The client would have stored a ton of information from the last time it
connected. Exactly what it stores will be implementations specific, but
it'll generally include something like:
prevServerFirst, prevServerLast
firstUnread - ID number of the first unread message on the server
lastUnread - ID number of the last unread message on the server
readmap - usually a sparse bitmap containing no more than
(lastUnread - firstUnread) entries...but potentially
being larger or smaller depending upon the implementation
numUnread - a count of unread entries in the aforementioned bitmap
On good days, the new serverFirst and the new serverLast are monotonically
increasing numbers. On such days, the code is easy to write and you don't
see strange numbers for the unread count.
On bad days, the new serverFirst may be smaller than the previous
serverFirst...and the code is substantially more convoluted to write.
On really bad days, the new serverLast may be smaller than the previous
serverFirst...and the code is really substantially more convoluted to write.
4) Some implementations might actually ask how many new messages have been
received since the last time the client and server connected. This is
typically done with a "time stamp" based command.
#####
Somehow I think I didn't clear anything up.
It's not uncommon for certain NNTP servers to arbitrarily do stupid things
that confuse NNTP clients that haven't encountered that particular idiom of
stupidity before.
It's not uncommon for NNTP clients to incorrectly rely on serverCount.
It's not uncommon for NNTP servers to lie about the number of messages
they've received since the last connection. Especially if there is a
disagreement between the clocks of the client and the server.
It's not uncommon for NNTP servers to change their minds about just how many
messages that they have.
All in all, dealing with "stupid" NNTP servers is an exercise in iterative
debugging. And if you write your NNTP client "to the spec", you'll find
that the server screws up your lovely code.
Just one of the reasons to ensure that you implement a "Mark All Messages As
Read" that really does...regardless of what the server has to say. ;-)
Nope...still no real useful information...but I ain't trying no more
tonight.
mikel
--
To unsubscribe: <mailto:[EMAIL PROTECTED]>
To search the archives:
<http://www.mail-archive.com/entourage-talk%40lists.boingo.com/>
