Re^2: Sockets, autoflush, and TCP

Tks for the replies everyone...

I'd would agree with you, but I believe that the buffering is coming directly out of the machine. I'm running the packet sniffer (tcpdump) directly on the computer sending the data which is where is see the "oversized" packet being put onto the wire. (oversized = a packet with more than one read from the barcode scanner)

targetsmart: Sorry for not being clear. I am receiving data from the barcode scanner on the serial port (/dev/ttyS0). The each barcode comes in with a CR at the end; I use that to delimit the individual barcode reads within my script and write each barcode to the socket independently.

Does that clear it up any?

Comment on Re^2: Sockets, autoflush, and TCP_NODELAY

Replies are listed 'Best First'.
Re^3: Sockets, autoflush, and TCP_NODELAY by BrowserUk (Patriarch) on Apr 21, 2009 at 03:23 UTC
A couple of questions that may not mean anything: Is there any pattern to the coalesced packets? Eg. Are they always a short one followed by another (short or long). What do you get if call getsockopt() on the sending machine for the following options? SO_SNDLOWAT SO_SNDTIMEO SO_SNDBUF 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."	[reply]
Re^4: Sockets, autoflush, and TCP_NODELAY by packetwhacker (Initiate) on Apr 21, 2009 at 17:17 UTC
1. Not really. I've attempted to make the situation worse by increasing the transmit rate on the scanner just to see what the script does. As the transmit rate increases, the number of packets with more than one read from the scanner increases. As far as a pattern is concerned, there's not one I can distinguish. 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: SO_SNDLOWAT = 1 SO_SNDTIMEO = (undef?) SO_SNDBUF = 16384 Thanks!	[reply]
Re^5: Sockets, autoflush, and TCP_NODELAY by BrowserUk (Patriarch) on Apr 21, 2009 at 17:50 UTC
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."	[reply] [d/l] [select]