Path: csiph.com!goblin1!goblin.stu.neva.ru!usenet.stanford.edu!not-for-mail
From: Ilkka Virta <itvirta@iki.fi>
Newsgroups: gnu.bash.bug
Subject: Re: bash sockets: printf \x0a does TCP fragmentation
Date: Sat, 22 Sep 2018 13:30:02 +0300
Lines: 24
Approved: bug-bash@gnu.org
Message-ID: <mailman.1132.1537612219.1284.bug-bash@gnu.org>
References: <c6de6616-dda0-570d-de56-419e7676be8a@cbii-hh.de> <20180921231101307758654@bob.proulx.com> <714e1ba0-0052-2f2b-676d-778f2b7129c1@testssl.sh>
NNTP-Posting-Host: lists.gnu.org
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: bug-bash@gnu.org
To: dirk+bash@testssl.sh, Bob Proulx <bob@proulx.com>
Envelope-to: bug-bash@gnu.org
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
In-Reply-To: <714e1ba0-0052-2f2b-676d-778f2b7129c1@testssl.sh>
Content-Language: en-US
Precedence: list
Xref: csiph.com gnu.bash.bug:14633

On 22.9. 12:50, dirk+bash@testssl.sh wrote:
> cat has a problem with binary chars, right? And: see below.

No, it just loops with read() and write(), it shouldn't touch any of the 
bytes (except for cat -A and such). But it probably doesn't help in 
coalescing the write blocks, it's likely to just write() whatever it 
gets immediately.

And you can't really solve the issue at hand by piping to any 
intermediate program, as that program couldn't know how long to buffer 
the input. Unless you use something that buffers for a particular amount 
of time, which of course causes a unnecessary delay.

The coreutils printf seems to output 'foo\nbar\n' as a single write, 
though (unless it goes to the terminal, so the usual stdio buffering), 
so you might be able to use that.


In any case, if a TCP endpoint cares about getting full data packets 
within a single segment, I'd say it's broken.

-- 
Ilkka Virta / itvirta@iki.fi