6 ms·

It's really not all that complicated. You get a couple of these Ethernet to 100FX converters: http://antaira.com/products/media-converters/unmanaged-converters

It's really not all that complicated. You get a couple of these Ethernet to 100FX converters: http://antaira.com/products/media-converters/unmanaged-converters/10-100tx-to-100fx/fcu-100sc?pid=200&gclid=CjwKEAjwqLWrBRC-_OaG-IfL0kASJAAbzKsVw109PZC7D5CTk_VjXs7TnEtSYRLjn0NfrpsCkI5Z1BoCTLLw_wcB http://antaira.com/products/media-converters/unmanaged-conve... Then you hook them up with just one fibre strand (instead of the usual 2). You obviously can't use TCP over that since that requires a 2-way connection, but UDP works just fine. You'll probably want to wrap your data in some error correcting code, too.

toomuchtodo 11y ago
> You'll probably want to wrap your data in some error correcting code, too. I've found that using hashes and sending duplicates of the data seems to weed out any transmission issues in a one way system.
- sdenton4 11y ago
  sure, at a communication complexity of 2N+k, where k is the hash size.... Error correcting codes allow much shorter error-free communications, with lower probability of failure than your method. Consider an N bit stream of data, with a probability mu of any given bit being flipped. Then the probability of your stream containing an error is gamma := 1-(1-mu)^N. Since you're sending the identical stream twice, there's a 1-(1-gamma)^2 chance that your overall transmission is unrecoverable. The hash will tell you that the transmission failed, but not how to correct it. Furthermore, there's a probability that your hash has a bit flipped somewhere, too... An error correcting code makes a guarantee that if up to m bits are flipped, the original message can be recovered exactly. A Reed-Solomon code can correct up to m errors while adding just 2m bits to the message length; even with a pretty conservative upper bound on the number of expected errors, this should be way less than 2N+k.

toomuchtodo 11y ago

> You'll probably want to wrap your data in some error correcting code, too. I've found that using hashes and sending duplicates of the data seems to weed out any transmission issues in a one way system.

sdenton4 11y ago
sure, at a communication complexity of 2N+k, where k is the hash size.... Error correcting codes allow much shorter error-free communications, with lower probability of failure than your method. Consider an N bit stream of data, with a probability mu of any given bit being flipped. Then the probability of your stream containing an error is gamma := 1-(1-mu)^N. Since you're sending the identical stream twice, there's a 1-(1-gamma)^2 chance that your overall transmission is unrecoverable. The hash will tell you that the transmission failed, but not how to correct it. Furthermore, there's a probability that your hash has a bit flipped somewhere, too... An error correcting code makes a guarantee that if up to m bits are flipped, the original message can be recovered exactly. A Reed-Solomon code can correct up to m errors while adding just 2m bits to the message length; even with a pretty conservative upper bound on the number of expected errors, this should be way less than 2N+k.