Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.networking > #1071 > unrolled thread

Data sent through sockets are *sometimes* inverted ?!!!

Back to article view | Back to comp.os.linux.networking

Contents

  Data sent through sockets are *sometimes* inverted ?!!! mast4as <mast4as@yahoo.com> - 2012-02-17 00:38 -0800
    Re: Data sent through sockets are *sometimes* inverted ?!!! Chris Davies <chris-usenet@roaima.co.uk> - 2012-02-17 09:50 +0000
    Re: Data sent through sockets are *sometimes* inverted ?!!! Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-02-17 10:25 +0000
      Re: Data sent through sockets are *sometimes* inverted ?!!! Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2012-02-17 13:42 -0700
        Re: Data sent through sockets are *sometimes* inverted ?!!! Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-02-19 19:50 +0000
          Re: Data sent through sockets are *sometimes* inverted ?!!! Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2012-02-19 21:19 -0700
            Re: Data sent through sockets are *sometimes* inverted ?!!! Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-02-20 09:01 +0000
              Re: Data sent through sockets are *sometimes* inverted ?!!! Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-02-22 08:56 +0000
                Re: Data sent through sockets are *sometimes* inverted ?!!! Jerry Peters <jerry@example.invalid> - 2012-02-22 22:59 +0000
                  Re: Data sent through sockets are *sometimes* inverted ?!!! Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-02-23 00:13 +0000
                    Re: Data sent through sockets are *sometimes* inverted ?!!! Ralph Spitzner <rasp@spitzner.org> - 2012-02-23 06:00 +0100
                      Re: Data sent through sockets are *sometimes* inverted ?!!! Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-02-23 07:34 +0000
                        Re: Data sent through sockets are *sometimes* inverted ?!!! Chris Davies <chris-usenet@roaima.co.uk> - 2012-02-23 11:12 +0000
                          Re: Data sent through sockets are *sometimes* inverted ?!!! Rick Jones <rick.jones2@hp.com> - 2012-02-24 19:25 +0000
                            Re: Data sent through sockets are *sometimes* inverted ?!!! Chris Davies <chris-usenet@roaima.co.uk> - 2012-02-24 21:03 +0000
                            Re: Data sent through sockets are *sometimes* inverted ?!!! Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-02-25 04:49 +0000
                              Re: Data sent through sockets are *sometimes* inverted ?!!! Chris Davies <chris-usenet@roaima.co.uk> - 2012-02-26 12:18 +0000
                              Re: Data sent through sockets are *sometimes* inverted ?!!! Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> - 2012-02-26 14:10 +0100
                                Re: Data sent through sockets are *sometimes* inverted ?!!! Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-02-26 14:02 +0000
                        Re: Data sent through sockets are *sometimes* inverted ?!!! Ralph Spitzner <rasp@spitzner.org> - 2012-02-23 17:03 +0100
                          Re: Data sent through sockets are *sometimes* inverted ?!!! Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2012-02-23 10:17 -0700
                        Re: Data sent through sockets are *sometimes* inverted ?!!! Grant Edwards <invalid@invalid.invalid> - 2012-02-23 19:13 +0000
                          Failing TCP checksums (was Re: Data sent through sockets are *sometimes* inverted ?!!!) Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-02-23 20:40 +0000
                    Re: Data sent through sockets are *sometimes* inverted ?!!! Jerry Peters <jerry@example.invalid> - 2012-02-23 21:34 +0000
                      Re: Data sent through sockets are *sometimes* inverted ?!!! Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-02-23 22:12 +0000
                      Re: Data sent through sockets are *sometimes* inverted ?!!! Grant Edwards <invalid@invalid.invalid> - 2012-02-24 15:23 +0000
                    Re: Data sent through sockets are *sometimes* inverted ?!!! Jorgen Grahn <grahn+nntp@snipabacken.se> - 2012-02-25 10:54 +0000
    Re: Data sent through sockets are *sometimes* inverted ?!!! Richard Kettlewell <rjk@greenend.org.uk> - 2012-02-17 10:07 +0000

Page 2 of 2 — ← Prev page 1 [2]

#1090

Ralph Spitzner <rasp@spitzner.org> writes:

> Jorgen Grahn wrote:
> [...]
>> 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.)
>
> Well if the connection somehow gets interrupted write will return
> a number less that the number of bytes you fed to it.
>
> [....]
>> Why? TCP doesn't lose bytes[1]; only programming errors cause that.
>>
>> /Jorgen
>>
>> [1] Except the rare cases where packets get corrupted in transit
>>      in such a way that the checksum is still valid.
>>
>
> Well yes, but the OP _believes_that TCP is doing some evil to his data,
> apart from this not being true and not knowing his programming
> techniques and/or skills, a checksum might help him :-P

At this point, the OP seems to have vanished back into the wilderness.
However, I think making sure he's really writing and reading all the
bytes he thinks he is will help him a lot more than adding another
checksum in his own code.

Note that my earlier observation that I don't remember ever seeing a
partial write() wasn't a result of an experiment seeing if I could
trigger it, it was just an observation of what I've encountered in
debugging my own code.  It is interesting, though, to see people
experimenting with trying to find circumstances under which it can
happen.

[toc] | [prev] | [next] | [standalone]

#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 ...

[toc] | [prev] | [next] | [standalone]

#1093 — Failing TCP checksums (was Re: Data sent through sockets are *sometimes* inverted ?!!!)

On Thu, 2012-02-23, Grant Edwards wrote:
> On 2012-02-23, Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:
...
>> [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.

Richard W. Stevens did a nice investigation of this; it's in TCP/IP
Illustrated, I think. He looked at live data and could tell that back
then, a non-negligable number of packets which get corrupted pass both
the Ethernet and TCP checksum. Enough so you have to consider it when
designing application protocols.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#1094

Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:
> On Wed, 2012-02-22, Jerry Peters wrote:
>> Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:
>>> On Mon, 2012-02-20, Jorgen Grahn wrote:
>>>> On Mon, 2012-02-20, Joe Pfeiffer wrote:
>>>>> Jorgen Grahn <grahn+nntp@snipabacken.se> writes:
>>>>>
>>>>>> On Fri, 2012-02-17, Joe Pfeiffer wrote:
>>> ...
>>>>>>> write() is also not guaranteed to send all the bytes out in a single
>>>>>>> try, so careful programming would require a similar loop for your
>>>>>>> write()s.  I've never actually seen a write() do anything but either
>>>>>>> send all the bytes or else fail, however.
>>>>>>
>>>>>> Have you looked? If you have a TCP socket with just N bytes of free Tx
>>>>>> buffer, and you write N+1 bytes to it, I'd expect a partial write to
>>>>>> happen.  I'd consider /not/ handling that case a serious bug.
>>>>>
>>>>> Yes, I have -- as part of debugging more instances than I want to admit
>>>>> to of discovering I wasn't doing a good enough job of what we discuss
>>>>> above.
>>>>>
>>>>> I've wound up dumping lots and lots of "tried to write %d, write
>>>>> returned %d" and I can't remember ever seeing an instance of something
>>>>> other than -1 or what I was trying to send.  It's an easy enough
>>>>> loop to write that I always do it (you're right, not handling the case
>>>>> would be a bug that might turn up now and might turn up in a decade),
>>>>> but so far I can't remember ever going around that loop twice.
>>>>
>>>> Interesting -- I must try it tonight. (On Linux, since I don't have
>>>> easy access to any other Unix outside work.)
>>> 
>>> So far I have failed to disprove what you wrote. Netcat to a
>>> SIGSTOPped server, until first the server's RX buffer got filled and
>>> then the client's TX buffer got filled. The client blocked instead of
>>> performing a partial write.
> 
>> What happens if you set the socket to non-blocking?
> 
> Something else, probably. But at this point I'd rather look at the
> linux/net/ sources -- when I have the time and energy.
> 
> Noone here has claimed that you don't need to check for partial writes,
> but it could be very useful to know (e.g. for debugging purposes) how
> Linux behaves in this case.
> 
> /Jorgen
> 
Why? The behavior could change at the next kernel upgrade.

But how do you know how it behaves in all circumstances? What about a
loaded server, where the problem is *NOT* the client has stopped
accepting packets, but the server is running low on transmit buffers?

	Jerry

[toc] | [prev] | [next] | [standalone]

#1095

On Thu, 2012-02-23, Jerry Peters wrote:
> Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:
...
>> Noone here has claimed that you don't need to check for partial writes,
>> but it could be very useful to know (e.g. for debugging purposes) how
>> Linux behaves in this case.

> Why? The behavior could change at the next kernel upgrade.

Yes, but it's still useful to know how your code usually behaves in
run-time, isn't it?

A concrete example: an application fails, and when you read the code
you find it doesn't handle partial writes correctly. Should you focus
on this, or keep looking elsewhere?

> But how do you know how it behaves in all circumstances? What about a
> loaded server, where the problem is *NOT* the client has stopped
> accepting packets, but the server is running low on transmit buffers?

Look, all I'm trying to do is find one scenario where partial writes
happen.  It started upthread, when Joe Pfeiffer said he had (almost)
never seen it, while my base assumption was that it was common in
anything but the most naive tests.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#1096

On 2012-02-23, Jerry Peters <jerry@example.invalid> wrote:
>
>> Noone here has claimed that you don't need to check for partial writes,
>> but it could be very useful to know (e.g. for debugging purposes) how
>> Linux behaves in this case.
>
> Why? The behavior could change at the next kernel upgrade.

One reason may be that in a good design, the way such exceptions are
handled depends on the frequency with which they occur.

> But how do you know how it behaves in all circumstances? What about a
> loaded server, where the problem is *NOT* the client has stopped
> accepting packets, but the server is running low on transmit buffers?

Nobody's arguing that it doesn't have to be handled correctly, but
choosing an optimum way to handle it is easier if you know how often
and under what circumstances it happens.  If it happens on 80% of
write() calls you handle it entirely diffently if it happens once or
twice a decand and only when you've received a signal during the
write().

-- 
Grant Edwards               grant.b.edwards        Yow! Let me do my TRIBUTE
                                  at               to FISHNET STOCKINGS ...
                              gmail.com            

[toc] | [prev] | [next] | [standalone]

#1102

On Thu, 2012-02-23, Jorgen Grahn wrote:
> On Wed, 2012-02-22, Jerry Peters wrote:
>> Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:
>>> On Mon, 2012-02-20, Jorgen Grahn wrote:
>>>> On Mon, 2012-02-20, Joe Pfeiffer wrote:
>>>>> Jorgen Grahn <grahn+nntp@snipabacken.se> writes:
>>>>>
>>>>>> On Fri, 2012-02-17, Joe Pfeiffer wrote:
>>> ...
>>>>>>> write() is also not guaranteed to send all the bytes out in a single
>>>>>>> try, so careful programming would require a similar loop for your
>>>>>>> write()s.  I've never actually seen a write() do anything but either
>>>>>>> send all the bytes or else fail, however.
>>>>>>
>>>>>> Have you looked? If you have a TCP socket with just N bytes of free Tx
>>>>>> buffer, and you write N+1 bytes to it, I'd expect a partial write to
>>>>>> happen.  I'd consider /not/ handling that case a serious bug.
>>>>>
>>>>> Yes, I have -- as part of debugging more instances than I want to admit
>>>>> to of discovering I wasn't doing a good enough job of what we discuss
>>>>> above.
>>>>>
>>>>> I've wound up dumping lots and lots of "tried to write %d, write
>>>>> returned %d" and I can't remember ever seeing an instance of something
>>>>> other than -1 or what I was trying to send.  It's an easy enough
>>>>> loop to write that I always do it (you're right, not handling the case
>>>>> would be a bug that might turn up now and might turn up in a decade),
>>>>> but so far I can't remember ever going around that loop twice.
>>>>
>>>> Interesting -- I must try it tonight. (On Linux, since I don't have
>>>> easy access to any other Unix outside work.)
>>> 
>>> So far I have failed to disprove what you wrote. Netcat to a
>>> SIGSTOPped server, until first the server's RX buffer got filled and
>>> then the client's TX buffer got filled. The client blocked instead of
>>> performing a partial write.
>
>> What happens if you set the socket to non-blocking?
>
> Something else, probably. But at this point I'd rather look at the
> linux/net/ sources -- when I have the time and energy.

The kernel logic is in tcp.c:tcp_sendmsg() ... but it's a large
function, largely undocumented, with GOTOs back and forth. It would
take me at least a day to understand it.

It seems though that buffering happens on skbuf basis rather than
octet basis, so I suppose that helps avoiding partial writes --
whatever you write(), you're either blocked or your data is packaged
and put on queue.

More experiments with a blocking TCP socket showed that:
- RST can trigger a partial write
- a signal (SIGSTOP) can, too
- I couldn't force a partial write in any other way, e.g. SIGSTOPping
  the peer
- I couldn't force partial writes by writing much more than my MSS at
  a time, either (I'm on plain Ethernet, and tried writing 10k at a
  time)

Experiments with a non-blocking TCP socket showed that:
- if TCP can't keep up, you get plenty of partial writes,
  even if you write just 50 octets at a time

I don't see the connection between what I saw in practice and
tcp_sendmsg(), but I haven't really tried.

I guess this boils down to, for blocking sockets, on a recent Linux:
- you shouldn't optimize your code for the partial write case
- you need to test that code path some other way, probably
  using signals

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#1079

mast4as <mast4as@yahoo.com> writes:
> I have a simple client/server apps where the client send data (TCP/IP)
> in the form of square of pixels colors (3 floats) to the server. I can
> change the size of the square but by default, I started with something
> like 32x32 pixels. So overall that's packets of 32*32*3*8 (8 bytes per
> float) floats sent to the server. These packets are send to the server
> for an entire image which can be say 1024x1024 in resolution. For my
> testing I set the pixel color to always be 1 0 0.1.
>
> On the client side:
> * 1 write -> 4 integers to specify pos and size of the square in the
> frame
> * 1 write -> square dim^2 * 3 (RGB) * 8 bytes pixel color data
>
> On the server side I do 2 reads:
> * do a first read to find the dimension and position of the square in
> the frame with 1 read
> * read all the pixels for the current square (square size^2 * 3 (RGB)
> * 8 bytes) with 1 read
>
> It runs okay but occasionally the squares have wrong values. For a
> block of 32x32 pixels say the first 20 pixels have RGB values that are
> 1 0 0.1 then the next 20 pixels have their RGB inverted say: 0 0.1 1
> then the rest of the pixels will be 0.1 0 1 say. This problem only
> happens when the square reach a certain size. When the square are 8x8
> or 16x16.
> 
> So I was wondering if it is possible that when the packed of data sent
> is too big, that the order of the bytes changes when it's read by the
> server.

TCP does not reorder bytes.

> Or is this not supposed to happen at all which would suggest a bug in
> the code (however I really checked that I was writing and reading the
> correct number of bytes so I find that strange).

Without seeing your code it's impossible to tell what's going wrong, but
a very common error is to assume that write() sends everything you ask
in one go or that each read() corresponds exactly to one write().

-- 
http://www.greenend.org.uk/rjk/

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.os.linux.networking

csiph-web