> -----Original Message----- > From: linux-net-owner@xxxxxxxxxxxxxxx [mailto:linux-net-owner@xxxxxxxxxxxxxxx] On Behalf Of Al Lanot > Sent: Tuesday, June 15, 2010 11:47 AM > To: David F > Cc: linux-net@xxxxxxxxxxxxxxx > Subject: Re: data gets corrupted (c sockets) > > I would never imagine that even though the write function returns the > number of bytes > "written" to the file/socket/whatever, it doesn't mean that it's > really there right on time. > > As I said in the first post, I suspected it had something to do with > buffering, but didn't > know how to check whether the data was delivered or not since I have > no interaction > with the browser on the client side. > > Thank you. > > On Mon, Jun 14, 2010 at 9:23 PM, David F <linux-net@xxxxxxxxxxxxxxxx> wrote: > > I had to go and open my big mouth... > > > > Well, I could not replicate "corrupted" data at the end of the file, but > > rather "missing" data... > > Delaying before closing the socket file-descriptor seems to fix it. I first > > tried setting the SO_LINGER and TCP_LINGER2 socket-options both to no avail > > -- I don't know why but I'm sure that someone else on this list can supply > > both an explanation and also a much nicer solution; nonetheless, ugly though > > it is, this one worked for me. > > > > -- David Favro > > Just a thought: A call to shutdown(sd, SHUT_WR) followed by a read(sd) until read() sees a close at the other end (via a return from read() of 0) instead of close() on the socket might give you more visibility into whether the local TCP stack thinks it has delivered all of the data to the client. Jeff Haran Brocade -- To unsubscribe from this list: send the line "unsubscribe linux-net" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
