karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) (10/19/88)
Another article has been found to be trashed by someone along the way. Would involved systems please take a look at what's going on out there? We got this article twice and the second one has a damaged Message-ID which caused a local DEC-20 NNTP newsreader to lose its mind. Fletcher Mattox at UTexas confirmed that the article was OK when it left his system, as it was when the 1st copy got here. Headers follow, please note Path: and Message-ID:. Original copy of article, in good condition: Path: tut.cis.ohio-state.edu!cs.utexas.edu!dvorak From: dvorak@cs.utexas.edu (Dan Dvorak) Newsgroups: alt.next,ut.general,comp.sys.mac,comp.misc,comp.os.misc Subject: Re: NeXT press release (very long but interesting) Summary: Price comparison of NeXT, Sun, Apple, & Compaq. Message-ID: <3580@cs.utexas.edu> Date: 14 Oct 88 01:52:13 GMT References: <5423@juniper.uucp> Organization: U.Tx@Austin Dept of Computer Sciences Lines: 28 Second copy of article, damaged: Path: tut.cis.ohio-state.edu!osu-cis!killer!ames!amdahl!pyramid!hplabs!ucbvax!rutgers!cs.utexas.eds!dvorak From: dvorak@cs.utexas.edu (Dan Dvorak) Newsgroups: alt.next,ut.general,comp.sys.mac,comp.misc,comp.os.misc Subject: Re: NeXT press release (very long but interesting) Summary: Price comparison of NeXT, Sun, Apple, & Compaq. Message-ID: <3580@cs.utexas.eds:< Date: 14 Oct 88 01:52:13 GMT References: <5423@juniper.uucp> Organization: U.Tx@Austin Dept of Computer Sciences Lines: 28 --Karl
lmb@vsi1.UUCP (Larry Blair) (10/20/88)
In article <25047@tut.cis.ohio-state.edu> karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) writes:
=Another article has been found to be trashed by someone along the way.
=
=Original copy of article, in good condition:
=
=Message-ID: <3580@cs.utexas.edu>
=
=Second copy of article, damaged:
=
=Message-ID: <3580@cs.utexas.eds:<
When you consider how susceptible to noise modem connections are, I find it
amazing that you don't see this 10 times a day. Actually, we probably do,
but it goes unnoticed. Maybe that would explain at least some of the times
when you see the (apparently) same article twice.
Maybe there should be a "Crc:" field in the header. Old news versions
would ignore it, but the new versions could throw away the article and
generate a "sendme" for the Message-ID.
--
Larry Blair ames!vsi1!lmb lmb%vsi1.uucp@ames.arc.nasa.govdtynan@sultra.UUCP (Der Tynan) (10/20/88)
In article <1118@vsi1.UUCP>, lmb@vsi1.UUCP (Larry Blair) writes: > > Maybe there should be a "Crc:" field in the header. Old news versions > would ignore it, but the new versions could throw away the article and > generate a "sendme" for the Message-ID. > -- > Larry Blair ames!vsi1!lmb lmb%vsi1.uucp@ames.arc.nasa.gov This won't work. If the CRC is corrupt, then NOTHING in the article is OK, including the Message-ID. What happens if the modem damage does something like putting a tab in the Message-ID (sound familiar? - how many sendme's does it take to get a microsoft article?? :-). If the CRC is shot, then bye-bye article. Of course, why fix the problem by changing news, when the *real* problem is a buggy uucp connection. Of course this isn't a perfect world, or anything... - Der -- Reply: dtynan@sultra.UUCP (Der Tynan @ Tynan Computers) {mips,pyramid}!sultra!dtynan Cast a cold eye on life, on death. Horseman, pass by... [WBY]
karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) (10/20/88)
lmb@vsi1.UUCP (Larry Blair) writes:
When you consider how susceptible to noise modem connections are, I find it
amazing that you don't see this 10 times a day. Actually, we probably do,
but it goes unnoticed. Maybe that would explain at least some of the times
when you see the (apparently) same article twice.
I don't buy that for a moment, sorry. Files already get checked for
validity during the transfer process by UUCP. If the file was
accepted at the receiving site, then it was a correct file. If that
couldn't be guaranteed, then UUCP would have been lost as a file xfer
method years and years ago.
--Karllmb@vsi1.UUCP (Larry Blair) (10/20/88)
In article <2584@sultra.UUCP> dtynan@sultra.UUCP (Der Tynan) writes: >In article <1118@vsi1.UUCP>, lmb@vsi1.UUCP (Larry Blair) writes: >> >> Maybe there should be a "Crc:" field in the header. Old news versions >> would ignore it, but the new versions could throw away the article and >> generate a "sendme" for the Message-ID. >This won't work. If the CRC is corrupt, then NOTHING in the article is OK, >including the Message-ID. This is not a problem because if the Message-ID is corrupted, the sendme will be just be requesting a nonexistent article. Not a problem. There is a problem with sending a sendme, though. You can only send it to a feed that is also running the crc check, otherwise a loop will result. A possible way to tell might be to use a different to.site group for these, such as to.site.crc. Only sites with crc checking create the group. -- Larry Blair ames!vsi1!lmb lmb%vsi1.uucp@ames.arc.nasa.gov
randy@umn-cs.CS.UMN.EDU (Randy Orrison) (10/21/88)
In article <1118@vsi1.UUCP> lmb@vsi1.UUCP (Larry Blair) writes: |In article <25047@tut.cis.ohio-state.edu> karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) writes: |=Original copy of article, in good condition: |= |=Message-ID: <3580@cs.utexas.edu> ^ |= |=Second copy of article, damaged: |= |=Message-ID: <3580@cs.utexas.eds:< ^^ People often do global changes of '>' to something else to fool the inews line counter. Perhaps a better fix is to have inews check message ids in articles being posted and complain if the ids have been munged; on the other hand this wouldn't help with people who don't use real news (UUPC type things, for example). -randy -- Randy Orrison, Chemical Computer Thinking Battery -- randy@cctb.mn.org (aka randy@{ux.acss.umn.edu, umn-cs.uucp, umnacca.bitnet, halcdc.uucp}) "Nondeterminism means never having to say you are wrong."
karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) (10/21/88)
randy@umn-cs.CS.UMN.EDU (Randy Orrison) writes: |=Message-ID: <3580@cs.utexas.eds:< ^^ People often do global changes of '>' to something else to fool the inews line counter. Perhaps a better fix is to have inews check message ids in articles being posted and complain if the ids have been munged... Um...The Message-ID: is generated by inews directly, not by the person writing a note. Perhaps you were thinking of bad changes to the References: line? --Karl
csg@pyramid.pyramid.com (Carl S. Gutekunst) (10/23/88)
It's munged here, and in fact we got *only* the munged version. That narrows the list of possibly corrupting sites to: Path: pyramid!hplabs!ucbvax!rutgers all of which are "known" clean sites with extremely high loads (each greater than 20 news connections). Stray alpha particles, perhaps? :-) <csg>