Random thoughts about software, hardware and electronics. And other things too...
lauantai 5. elokuuta 2017
Transmit errors
When you dig down deep enough, everything is analog. And this means certain degree of uncertainty.
I've mentioned WiFi module I'm using previously, and deep down the communication with it - via serial link - is again nothing more than stream of bytes. It's up to application to assign meaning to that with software.
And boy, is that fun. The protocol the module uses assumes that serial link is mostly immune to transmission errors - that is, that absolutely no bytes are corrupt or lost during transmission from the main processor to the module or the other way around. If a singly byte is lost, synchronization is lost and data received becomes incomprehensible. And since frame format has no checksum, single corrupt byte may render entire transmission (either single frame, or your gigabyte data within) irrelevant or at least broken until repaired.
So, while the underlying TCP/IP link (assuming that one is open at the moment) itself may be resistant to errors, suddenly the data link from the module to processor might not be (and in case of my application, it definitely isn't due to module being placed on an external module connected with cable). And this will easily lead to corrupt data being transmitted.
Fortunately I have a personal, deep distrust on data integrity of any such transmission link - be it point-to-point one inch serial link contained within a board, or wireless link over thousands of kilometres, so I have tendency to design my applications' data transfer protocols to contain rudimentary integrity checks too, in order to avoid just this kind of situation. If data is lost (to either way), connection (read: entire module, if error is persistent) is reset and application will try again.
Whether this is efficient depends on your point of view. Is it fastest way to transmit data? Absolutely not, as constant data transmits and respective acknowledgements take a lot of time, especially over slower links (protocols designed for fast but high-latency links are nice, but I don't have any at my disposal at the moment.) But then again, I'm not transmitting blockbuster movies at 4k resolution here, but infrequent, small(ish) data packets that I want to be processed by receiver exactly once. It's up to receiver to make sure received package is handled only once.
If you happen to be modern (web) programmer, working exclusively with high-level languages, this may seem a bit excessive to you. But when you're working on lower level, with no operating system or high-level language libraries to hide all the nasty details of unreliable links beneath, these things need to be done.
And guess what? I still like it, just the way it is. It might be unreliable, but still is fun to work with.
Tilaa:
Lähetä kommentteja (Atom)
Ei kommentteja:
Lähetä kommentti