paula@bcsaic.UUCP (Paul Allen) (12/26/89)
This is just information for anyone who may be interested. Parts 15, 23, 24, and 33 of the most recent big slug of 1.5 postings had no 'end' line as received at this site. I'll check with the archives before I ask for anything as drastic as a repost. :-) Paul Allen -- ------------------------------------------------------------------------ Paul L. Allen | pallen@atc.boeing.com Boeing Advanced Technology Center | ...!uw-beaver!bcsaic!pallen
DEDOUREK@unb.ca (12/28/89)
> This is just information for anyone who may be interested. Parts > 15, 23, 24, and 33 of the most recent big slug of 1.5 postings > had no 'end' line as received at this site. I'll check with the > archives before I ask for anything as drastic as a repost. :-) > > Paul Allen > At this NETNORTH/BITNET site, info minix postings often show up truncated; these have, so far, always been followed shortly by another copy which was not truncated. In the past, there have been messages which were received truncated up to a half dozen times; always eventually followed by a "good" version. Someone should investigate: (1) why these initial failures occur; (2) whether on other (e.g. USENET) networks, the initial bad copy is kept and the succeeding copies, including the final "good" copy are discarded as duplicates. John DeDourek dedourek@unb.ca -- Registered Domain Name DEDOUREK@UNB -- BITNET / NETNORTH (Canada) dedourek@unb.bitnet -- For mailers which only know how to get to bitnet this way.
overby@plains.UUCP (Glen Overby) (12/28/89)
In article <6961@nigel.udel.EDU> DEDOUREK@unb.ca writes: >At this NETNORTH/BITNET site, info minix postings often show up >truncated; these have, so far, always been followed shortly by >another copy which was not truncated. In the past, there have been >messages which were received truncated up to a half dozen times; >always eventually followed by a "good" version. The multiple copies of postings you receive are due to one of two things: the poster finds out that there were problems and reposts, or one of the RSCS (Remote Spooling bleah System) programs which runs on each Bitnet node had a glitch when transferring the file and restarted the file, but sent the interrupted one on anyway. Complain to IBM about this bug. I've known of the latter happening and some poor victom being sent hundreds of copies of the same letter. That is VERY bad. >Someone should investigate: (1) why these initial failures occur; >(2) whether on other (e.g. USENET) networks, the initial bad copy >is kept and the succeeding copies, including the final "good" copy >are discarded as duplicates. On Usenet, a posting should be kept once at any given site. Each site maintains a history file of Article-IDs it has recieved in recent time (normally it's news expiration time + a few days) and will drop any new copies of the article it recieves. There are few integrity checks done on articles, since it is assumed that the lower protocol layers are reliable enough to send an article between sites intact. All there is in an article is an "#!rnews count" line on each batch sent between sites, where count is the character count and a "Lines" header line which contains a line count. Philosphically, what SHOULD the news system do with a bad article?? Keep it? Throw it Away? Or keep it but leave a marker saying that if another copy is received that it should be kept. If the latter solution is taken, you could expect to read the same article two times if you have a bad link. That's a trade-off. Realistically, I doubt there is little that can and will be done about the overall reliability of today's News system. If a small number of sites are flakey, it might be possible to convice their system administrators to fix things. Beyond that, there is little we can do but live with it. There are worse problems to deal with... the biggest being incompatable networks. I did notice that the 1.5.0 articles took three or four different paths to get here via NNTP (I'm on NorthWestNet, an NSF regional network. I think Boeing.COM in Seattle is, too). -- Glen Overby <overby@plains.nodak.edu> uunet!plains!overby (UUCP) ncoverby@ndsuvax, overby@plains (Bitnet)