controlling tcp max time before send

[David Storrie]

I have an application which is occasionally not sending out its data immediately. Tracing and sniffing have shown that the write to the socket happens as expected, but the packet is not sent.

"man 7p tcp" indicates that it might be buffering until it gets an ack from the other side of the connection. However, it can be waiting up to 18 seconds.

I'm not sure if setting TCP_NODELAY would be the correct method of resolving the issue - is the socket going to wait for "write()" to complete before sending in this case? SO_SNDTIMEO sounds like it might be an avenue to investigate from the name, but I can't find any detail to its purpose.

[Massimo Bianchi]

See these link:

http://www5.itrc.hp.com/service/cki/docDisplay.do?docLocale=en_US&docId=200000065019969

http://www5.itrc.hp.com/service/cki/docDisplay.do?docLocale=en_US&docId=200000065018823

Massimo

[Suresh Patoria]

Hi,

I think your application have some port that is working on some port number

so you just check the /etc/inetd.conf file
if you found the services for your application then check in the line there is nowait for the TCP service

Thanx

[Suresh Patoria]

Hi,

I think your application have some port that is working on some port number

so you just check the /etc/inetd.conf file
if you found the services for your application then check in the line there is nowait for the TCP service

Thanx

[Steven Gillard_2]

Without TCP_NODELAY set the maximum delay you usually see is 200ms so I don't think thats coming into play if you're seeing delays of up to 18s.

Check your duplex setting on your lan card (lanadmin -x ), if there is a mismatch between the card and the switch this can cause lots of network errors which will cause this type of problem. If you're on 100bt set both the card and the switch to full-duplex with auto-neg off.

Its difficult to speculate what else this could be without seeing the network trace (and system call trace if you've got one).

Regards,
Steve