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
_______________________________________________
networking-discuss mailing list
[email protected]
