axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "nadir amra (JIRA)" <>
Subject [jira] Commented: (AXISCPP-749) Currently TCP_NODELAY is turned off. This is only efficient when the messages are small.
Date Sun, 23 Oct 2005 20:25:18 GMT
    [ ] 

nadir amra commented on AXISCPP-749:

Not sure what omission is?  The code is turning off buffering, so that small packets get sent
immediately without having to wait. This does not affect large chunks of data, which will
get sent. 

I do admit if we were doing writes of say 2-3 bytes of data 1000's of times, I would have
a problem with this option being sent. But we are not.

Can we close this issue?

> Currently TCP_NODELAY is turned off.  This is only efficient when the messages are small.
> -----------------------------------------------------------------------------------------
>          Key: AXISCPP-749
>          URL:
>      Project: Axis-C++
>         Type: Improvement
>   Components: Transport (axis3), Transport (Client)
>     Versions: current (nightly)
>  Environment: n/a
>     Reporter: Fred Preston
>     Priority: Trivial

> When setting up the socket, the following initialisation is performed (see the last few
lines of method HTTPChannel::OpenChannel() and HTTPSSLChannel::OpenChannel())...
>     /* Turn off the Nagle algorithm - Patch by Steve Hardy */
>     /* This is needed, because our TCP stack would otherwise wait at most
>      * 200 ms before actually sending data to the server (while waiting for
>      * a full packet). This limits performance to around 5 requests per
>      * second, which is not acceptable. Turning off the Nagle algorithm
>      * allows for much faster transmission of small packets, but may
>      * degrade high-bandwidth transmissions.
>      */
>     int one = 1;
>     setsockopt( m_Sock, IPPROTO_TCP, TCP_NODELAY, (char *) &one, sizeof( int));
> When the message is not so small, does this omission degrade the socket performance?
 Would it be better to set a threshold and perhaps change the socket options 'on the fly'
when the message size dictates that it should be handled differently?

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message