Wojciech Meler writes: > James Carlson wrote: > > I don't see how you can rule those out. And the TCP RST scenario > > (causing intentional buffer flush) seems particularly devastating. > > Is it solaris specific behavior to flush input buffers on RST? I'm not > sure but I think linux don't do it.
I don't think it's Solaris specific at all. You may want to check. Failing to flush on RST sounds like a pretty serious bug to me. > I don't care about client faults (such as segmentation faults) because > people got used to loose some data when they see an application crash. > They are annoyed when it seems that everything is working ok, but data > is lost. How do people "get used" to faults in _remote_ applications? I don't get it. Why is having the remote application run into a bad hair day anything different from having the network itself fail? > That's why I assume that acked data will be delivered. You've worried me > with this RST case but are you sure that input buffers are flushed? Positive. Look at tcp_clean_death(). > I > can understand that output buffers are no longer needed, but input > buffers can contain usable data. They get torched. > > The last data packet can't be "lost." It will be resent. > > I have bad experience with firewall that dropped connections after 12 > seconds of half-closed state. Connection beetwen firewall and client was > crowded so last data packet with FIN flag was not received by client. Agreed; middleboxes are inherently evil. There's not much that can be done about them but indenting them six feet downwards. > Server recieved RST in response to retransmition, but unfortunately > client did not, because it didn't sent any packet to server - it waits > for data. > So after that server closed connection - because it got RST on FIN > retransmition, but client hanged (timed out) waiting for data. So, how does TIOCOUTQ really work in the face of broken equipment? > So: > - I can't use lingering because I'll hang in close (single IO thread) > - I can't use shutdown because bad handling of half-closed connections > by firewalls and client timeouts > - I can use TINCOUTQ to see if all data are acked Really? Are you sure that TIOCOUTQ doesn't also return a complete falsehood due to the firewall misbehavior? How can you know? > what would you choose ? Application level mechanisms, first. If I decided I didn't care that much about reliability, then I wouldn't do any of the above. Just write and close. > In this case nonblocking close would be the best (it could return -1 and > errno=EAGAIN ) but would it be more portable ? I don't understand. That's effectively what shutdown _does_. It doesn't block, and it behaves as if you'd closed the connection, and it's portable. If you can't do that for some reason, then I don't think you can use a non-blocking close, either. > > Does TIOCOUTQ on a socket work anywhere _but_ Linux? I think you've > > created a requirement that essentially rules out any sort of > > portability. > > I'm not saying that it is portable. It is just nice feature that helps > in some situations. > On the other hand there is BrandZ community - if they wan't to run all > userspace linux apps they'll have to provide such feature. They'll not get much help from the kernel, I'd imagine. It looks like a pretty serious overhaul to get it _right_. Returning 0 would probably be the best answer there. -- James Carlson, KISS Network <[EMAIL PROTECTED]> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ networking-discuss mailing list [email protected]
