Quote:
Originally Posted by Slaughter /img/forum/go_quote.gif
It's a perfect analogy and you prove it by saying the audio will get to the other end without audible errors, thus proving that there is no difference between coax and optical. Thanks for clearing that up. And in case you didn't know, a transferred file doesn't always recover from transmission errors, thus the need for MD5 when we download large files. So again, they are exactly the same.
|
Hey fighting is not fun, but here goes. I sell file transfer services for a living, and the company I founded in my living room (now with over 100 employess and offices in 5 cities) is involved in moving 45% of the digital press releases in North America and 10% of feature news to newspapers every day over the internet.
I designed it all with W. Richard (Rich) Stevens, the author of Unix Network Programming (now unfortunately no longer with us), and he thanks me in the preface of Vol 2 and others of his books. I give speeches at news transmission meetings all over the world, and my company is considered the technology leader in the space by everyone.
Be careful if you try to take me on re file transfers. I have been studing the statistical properties of error propagation in communications for 40 years. I was an Member of Techincal Staff at Bell Labs. I have a BA from Princeton, summa cum laude, and a PhD from Yale, both in statistics. I won the Theory and Methods award from the Journal of the American Statistical Association, and have been selling file transfer software since 1981.
Standard file transfer protocols do have re-transmission and error correcting built in, and transfer perfectly if the transmission line stays up.
You have no idea what MD5 really is. A simple CRC-32 checksum will work for file integrity; MD5 is a cryptographically secure message digest used to stop tampering. It can be used as a simple check-sum on a file but that is overkill. There is typically no need in most environments to compute and verify a checksum; sometimes there is, it depends. Not relevant here.
Most file transfers have mild real-time requirements, or none. Streaming the bits in time to the music is not involved in file transfer. It is in digital audio.
It is as simple as that. Think about it. Streaming over the internet is the proper analogy to sending digital audio over a cable, not file transfers. As I said, some ethernet or WiFi digital audio protocols use buffers and can support re-transmits, up to a limit where the timing of the music takes over. That's a little like file transfer, but not much.
I only wanted to stop the "just bits" argument. It's: "bits AND timing". That's all. I don't want to fight. But I know my stuff, thank you, and your reply post used sarcasm, which is a no-no for me.
