Thanks, Greg, very well described. I, too, have always had trouble with programmers who have always had to "..test that what was sent is what we got.." with a bunch of extraneous, superfluous processing..
Regards
JP
>>> <[log in to unmask]> 04/24/02 09:20AM >>>
Can we agree that TCP/IP does ensure that if transmission over TCP/IP is
successful, then the recipient got what was sent? And, as such, while
application errors and resulting data errors may abound, check sums or
application level acknowledgements which amount to "I got your transmission
#123,456" are redundant, at least for ensuring that the transmission was
successful? With TCP/IP, I do not need to worry that packets were somehow
lost without me being able to determine that I didn't get the file, or that
bits got twiddled and the data got corrupted.
Sure, checksums may demonstrate the some programmer does not know how to
write a checksum routine, with the consequence that the application-level
checksum is wrong, and the data itself has some chance of also being wrong.
Because, if the programmer code the checksum logic incorrectly, the rest of
his code is equally suspect.
This is the argument I have with certain mainframers, who want files
transmitted over a reliable medium to include header and trailer records
(just like, what, a card deck?), some of which do not even include useful
checksums, totals, or record counts (just like a card deck), but are no more
than BEGIN and END (just like a card deck). If ftp worked, I got the file,
and no other validation that I got what was sent is necessary. If it failed,
both ends can tell that it failed, although the receiving end might not be
careful to confirm that. Not all platforms are as careful as the 3000 to not
leave me with a fraction of a file, although IBM mainframes allow me to
specify this behavior by sending site conddisp=d.
So, if someone's protocol sends a message to a socket on my system, I do not
need to explicitly send a reply at the application level. TCP/IP either ACKs
or NAKs. It's awfully fun during debugging and development to see such a
message, but in production, it's wasted.
Greg Stigers
http://www.cgiusa.com
* To join/leave the list, search archives, change list settings, *
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
|
