Hi James Carlson & all, James Carlson writes: > Yes; the IPPROTO_TCP, TCP_NODELAY socket option can be used to change > the way TCP deals with small writes from the application. Are there any other parameters that will control/affect the Nagles algorithm apart form TCP_NODELAY? i.e 1) Till when TCP buffers data ? does it buffer till the application data accumulates to fit into a segment? 2) is there any timer till when the buffering will happen (if the data is not fit into a segmet) and later sent on wire?
Best regards, Chandu On Tue, Oct 21, 2008 at 6:01 PM, James Carlson <[EMAIL PROTECTED]> wrote: > > chandu valesh writes: > > some where in the TCP layer). Now the previous response and the new > > application data are sent in the same segment of the TCP. This is not > > happening every time, but happening some times. Are there any parameters > > that will effect this behavior ( buffering of the application data etc)? > > Yes; the IPPROTO_TCP, TCP_NODELAY socket option can be used to change > the way TCP deals with small writes from the application. > > Several words of caution, though: > > - TCP is a byte-stream protocol. It doesn't respect any application > "record" boundaries other than individual bytes, it's not required > to do so, and can't be made to do that. If you need a record- > oriented protocol on IP, then pick among: > > + SCTP > + UDP with your own error control > + TCP with your own record-marking on top > > - Setting the TCP_NODELAY option turns off part of TCP's congestion > control mechanism and can result in far more packets on the wire. > It's likely not to be the right answer here. > > - This is a well-known issue. Google for it. > > > the application in the receiver responds to the request immediately, but it > > is delayed and sent later along with the other messages in the packet whose > > No is 4985. > > > > where could be the problem? > > I don't see a problem here; it looks like normal TCP delayed ack > behavior to me -- other than that the peer is sniping away the > connection for no apparent reason. > > (Isn't Diameter typically implemented on top of SCTP ... ?) > > -- > James Carlson, Solaris Networking <[EMAIL PROTECTED]> > Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 > MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 -- Chandu Valesh _______________________________________________ networking-discuss mailing list [email protected]
