Lists Home |
Date Index |
What do you use for data transfer??? I almost never get data corruption
that isn't corrected in some way, and I constantly use WiFi, CDMA2000
based cell Internet access, all kinds of computers, harddrives, etc.
Not since I last used my Jazz drive have I had the kind of corruption
you seem to be dealing with. I did have trouble with a particularly
ugly multi-drive RAID-5 failure, but files were either good or bad.
If the session layer, i.e. TCP/IP or the filesystem, doesn't find
errors, the application managing transfer should (email, etc.).
Certainly, the application, or better, the library that is accessing the
data should detect and react well to any data presented.
Elliotte Rusty Harold wrote:
> At 2:25 PM -0400 4/15/04, Stephen D. Williams wrote:
>> We're realistically talking about bugs or deficiencies in code,
>> configuration, mismatch between applications, etc., not 'fragile
>> things that break' from any perspective but schema co-evolution,
>> configuration management, and programmer error, isn't that right?
> No, it isn't. As well as outright bugs, you can have data corrupted or
> partially transmitted across the network, disks that develop bad
> sectors, and deliberate creation of bad data as a component of a
> denial of service attack. Do you want your system to crash because
> some hacker flipped a couple of bytes in the right place?
In my model, the esDOM library is accessing an esXML object for each
element, attribute, and text value, validating the structure as it
goes. If corruption is found, an exception will be thrown or an error
indicated. Where does crashing come in?
> You can add forward error correction, b64 or quoted text encoding, and
> other methods to prevent corruption, but the only cure for
> user/programmer/operator error is early error detection and clear
> warning. When these have already been taken care of, through earlier
> testing in once sense or another, or other methods, it is not an issue.
> There are multiple layers of corruption possible. Using check sums to
> verify the data helps at one layer, but does not protect against the
> same things well-formedness checking does. Well-formedness checking
> does not prevent attacks at the semantic layer though some validity
> checks might. Validity cannot prevent most social engineering
> attacks. Attacks take place at different points in the stack. Error
> correction (which is mostly handled by TCP anyway) is only one a
> shiedl against one kind fo attack.
I agree. You can't check enough at any layer to completely protect the
firstname.lastname@example.org http://www.hpti.com Per: email@example.com http://sdw.st
Stephen D. Williams 703-724-0118W 703-995-0407Fax 20147-4622 AIM: sdw