home *** CD-ROM | disk | FTP | other *** search
- ;S |
- ;S |
- ;S | THIS NODEDIFF MUST ONLY BE MERGED WITH A
- ;S | NODELIST.192 THAT HAS A VALID CRC VALUE OF
- ;S | 12600 AT THE RIGHT END OF THE FIRST LINE AND
- ;S | IS NOT LESS THAN 1,443,264 BYTES LONG.
- ;S |
- ;S |
- ;S | I F Y O U R N O D E L I S T . 1 9 9 D O E S N O T H A V E
- ;S |
- ;S | C R C V A L U E 1 2 6 0 0
- ;S |
- ;S | D O N O T P R O C E S S T H I S N O D E D I F F
- ;S |
- ;S |
- ;S | IF YOUR SOFTWARE HAD TROUBLE MERGING NODEDIFF.192
- ;S | WITH NODELIST.195 YOU WILL HAVE TROUBLE WITH THIS
- ;S | NODEDIFF. IN THAT CASE THE ONLY 100% SAFE SOLUTION
- ;S | IS TO OBTAIN FULL NODELIST.?99 FROM YOUR NETWORK OR
- ;S | REGION COORDINATOR AND RETURN TO NORMAL PROCESSING
- ;S | WHEN NODEDIFF.206 IS DISTRIBUTED.
- ;S |
- ;S |
- ;S | D O N O T T A M P E R W I T H T H I S N O D E D I F F T O
- ;S |
- ;S | M A K E I T W O R K . I F I T F A I L S T O M E R G E
- ;S |
- ;S | P L E A S E D O N O T T A K E C H A N C E S .
- ;S |
- ;S |
- ;S | A file called CRCNODE.ARC has been hatched into the COORDUTL
- ;S | file echo. The program can be executed wherever your nodelist
- ;S | is located to help with validation. If the program reports
- ;S | an error you should get a correct nodelist from your NC or RC.
- ;S |
- ;S |
- ;S | Several days ago I announced to the Zone 1 Region Coordinators
- ;S | that I planned to release NO nodediff.199 and release only a
- ;S | full nodelist.199 in its place. A majority of the Region
- ;S | Coordinators questioned that plan. They offered evidence that
- ;S | many, many of Zone 1's nets had already spent the weekend and
- ;S | part of this week preparing for distribution of nodediff.199.
- ;S | They indicated that although from my vantage point the no
- ;S | nodediff scenario was the "safe and easy" way to proceed they
- ;S | and the Network Coordinators all over Zone 1 could handle the
- ;S | situation without forcing everyone in the zone to accept a full
- ;S | nodelist. The RCs feel that this is a more cost effective
- ;S | solution as well as one that allows local solutions rather than
- ;S | ones dictated from far away. Their arguments were convincing and
- ;S | accepted as offered.
- ;S |
- ;S | If you don't fully follow what happened last week please read
- ;S | on. If you still have concerns about the nodelist on your system
- ;S | you should get a fresh one from your NC or RC or ZC in that
- ;S | order to share the load.
- ;S |
- ;S |
- ;S | Last week's Nodediff.192 created a little stir around zone 1. As
- ;S | the condensed story goes, a carriage return (CR or hex 0d) and a
- ;S | semicolon (;) sneaked into one network's segment as excess data
- ;S | and escaped detection by the MakeNL software that merges
- ;S | nodelist components on both the RC and ZC machines. Some ask
- ;S | "Isn't CR always the end of a line and not data?" Well, not if
- ;S | your software uses the C language text read routines to process
- ;S | network and region segments. Those routines require both CR and
- ;S | LF (linefeed) to appear together before they pay attention. But
- ;S | if your software uses the Pascal language text read routines CR
- ;S | is indeed seen as an end of line indicator the same as CR and LF
- ;S | together. That's our problem. Different interpretation of the
- ;S | same data.
- ;S |
- ;S | We have one program building the nodediff using one rule and
- ;S | many others processing it using another rule. As always, two
- ;S | opinions have been shared. One says MakeNL is broken. The other
- ;S | says certain nodelist compilers are broken. I think we've just
- ;S | found an exception that none of the programs were looking for.
- ;S |
- ;S | FidoNet nodediffs are based on a strict count of the number of
- ;S | lines in the nodediff itself and in the nodelist. If a line is
- ;S | added or deleted from either file, we have trouble. That's what
- ;S | the Pascal based programs reported last week while the C
- ;S | programs chugged along quietly.
- ;S |
- ;S | The Pascal based programs processed an A3 (Add the next 3 lines)
- ;S | command and added the next 3 lines they read. The line
- ;S | immediately after the 3 added lines was supposed to be another
- ;S | command -- Add, or Copy, or Delete. Remember that sneaky CR? Well,
- ;S | it joined forces with the Pascal read routines to make 4 lines out
- ;S | of 3. In this case the original third line following A3 became
- ;S | the fourth so the programs expected a command. It found
- ;S | Host,3808,... instead. That's a fatal error for any
- ;S | nodediff/nodelist merge program.
- ;S |
- ;S | Many of us saw that fatal error. Reactions varied from curiosity
- ;S | to anger. But thanks to the efforts of many folks the impact was
- ;S | reduced to a minor annoyance in all but a few remote areas.
- ;S |
- ;S | This week the ZC's machine is running nodelist checking software
- ;S | that hopes to either prevent occurrence of a similar event or
- ;S | not publish the nodediff if it does happen.
- ;S |
- ;S | We now know about a situation where data can sneak in and gum up
- ;S | the works. I suspect a few nodelist processing software authors
- ;S | are taking another look at FTS-0005 (our nodelist contents
- ;S | standard document) and shoring up their software to allow for
- ;S | similar situations in the future.
- ;S |
- ;S |
- ;S | Thanks for all your efforts.
- ;S | George Peace
- ;S |
-