Given that the overall rate of production under normal conditions is only about 1 unit per 2-3 seconds, I had tempered the scanner to transmit the data once and only once for a unit when I first noticed the problem. Even with this huge delay (to a computer anyways), I can still see an odd packet here and there that has more than one read in it.

As I mentioned earlier, I made the situation worse by increasing the transmit rate on the scanner. I did this by enabling an additional barcode format to be read and so now the scanner reads between two barcodes over and over quite quickly. This confirms for me that somewhere along the line my TX data is getting buffered somewhere. Knowing we all get stupid sometimes, I went in and added some prints to make *sure* that I'm only sending one complete scanner read per call to send(), or syswrite(). -- I've been flip-flopping between them to see which behaves better; neither so far.

2. As follows:

Thanks!

As the transmit rate increases, the number of packets with more than one read from the scanner increases.

That sounds very much like Nagle is still operating. Are you sure that your setsockopt( TCP_NODELAY ) was successful? Try using getsockopt() after you've set it, to see what you get. Some stacks (MS for example) have this habit of responding success to unupported options.

Another possibility would be to set the SO_SNDBUF size to the same size as each write prior to writing. If your packets were fixed size you could just set it once, but with your max packet size 3 times the minimum, that probably wouldn't help.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."