I’m sending small amounts of data over a TCP socket, and I’m getting delays around 2 seconds long. For the type of applications we’re developping, this delay is unacceptable.
I’ve tried setting the TCP_NODELAY socket option, but this doesn’t help.
I’m looking for a way to force the socket to send the information immediately. I know that TCP has a push flag, but I haven’t found a way to set it.
Any suggestions are welcome!
Steve
Any design that has some sort of timing expectation with TCP is a broken design in my humble opinion. The stack is free to do what it wants with the data.
That being said that 2 seconds is strange (I have seen a few tenth of a seconds), how big is your message. Can you post your code? What OS is at the other end? Are you sure it’s the stack at the receiving end that isn’t sending the data to the application?
Steve,
To further what Mario said about it being the receiving end, you might want to have a 3rd machine on the network running a sniffer (like ethereal) to see when the packets are sent to determine if the delay you are seeing is on the send or receive side of things.
I’ve never experienced delays anywhere near 2 seconds with either TCP or UDP sockets under QNX sending to both Windows and QNX machines. One thing to be aware of tho is that if your using 10 Mbit ethernet it may be very slow due to being 1/2 duplex (you may think your running at 100 Mbit speed but the QNX drivers can be finicky about auto-negotiation sometimes so it’s best to check with a switch that has lights that display the connection speed (10/100/1000).
The snippet of code Mario suggested posting would be the best way for us to help you determine what the problem is.
Tim
I don’t know if you worked this out or not, but for general information, using TCP_NODELAY is what sets the push flag. My current project is similar, but I have not experienced any delays such as you describe. It is hard to know what might be the problem without further diagnostics. For instance, have you been able to verify that the data is not showing up on the Ethernet wires until two seconds after it was passed to the TCP stack?
-Jim