Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!news.glorb.com!news-out.readnews.com!transit4.readnews.com!panix!not-for-mail
From: Grant Edwards <invalid@invalid.invalid>
Newsgroups: comp.os.linux.networking
Subject: Re: Data sent through sockets are *sometimes* inverted ?!!!
Date: Thu, 23 Feb 2012 19:13:31 +0000 (UTC)
Organization: PANIX Public Access Internet and UNIX, NYC
Lines: 27
Message-ID: <ji634r$1gn$1@reader1.panix.com>
References: <435969f4-8cf5-44d7-a46e-64c0a20223a8@e27g2000vbu.googlegroups.com> <slrnjjsao1.1ls.grahn+nntp@frailea.sa.invalid> <1bsji9i43k.fsf@pfeifferfamily.net> <slrnjk2kjq.1ls.grahn+nntp@frailea.sa.invalid> <1b1upq6ssg.fsf@pfeifferfamily.net> <slrnjk42um.1ls.grahn+nntp@frailea.sa.invalid> <slrnjk9bds.1ls.grahn+nntp@frailea.sa.invalid> <ji3s0a$cl5$1@dont-email.me> <slrnjkb15v.1ls.grahn+nntp@frailea.sa.invalid> <jptg19-klg.ln1@spitzner.org> <slrnjkbr0d.1ls.grahn+nntp@frailea.sa.invalid>
NNTP-Posting-Host: dsl.comtrol.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Trace: reader1.panix.com 1330024411 1559 64.122.56.22 (23 Feb 2012 19:13:31 GMT)
X-Complaints-To: abuse@panix.com
NNTP-Posting-Date: Thu, 23 Feb 2012 19:13:31 +0000 (UTC)
User-Agent: slrn/pre0.9.9-102 (Linux)
Xref: x330-a1.tempe.blueboxinc.net comp.os.linux.networking:1091

On 2012-02-23, Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:
> On Thu, 2012-02-23, Ralph Spitzner wrote:
>
>> Well write(2) and send(2) both return the number
>> of octets written, or -1.
>>
>> What's the question here ?
>
> The question is "under which situations does write() on a TCP socket
> return a partial write?". ("Partial write" meaning that some, but not
> all of the data you fed it got sent.)

My _guess_ is that a signal received during the write might cause
that, but I've never actually seen it happen nor have I analized the
kernel source code to see if it would.

> [1] Except the rare cases where packets get corrupted in transit
>     in such a way that the checksum is still valid.

I've seen that happen with Ethernet frames, but the TCP checksum
detected it and caused a retransmission.

-- 
Grant Edwards               grant.b.edwards        Yow! ... I think I'd
                                  at               better go back to my DESK
                              gmail.com            and toy with a few common
                                                   MISAPPREHENSIONS ...