Devart Forums

Hello,

I have setup a SSH client using TScSSHClient and TScSSHChannel classes with TClientSocket class as underlying socket.

Packet data exchanged are :
- commands consisting of text less than 100 bytes size.
- binary data of 512 bytes size.

I have read that when packets are less than 1460 bytes size a timer is set for 200ms until the underlying buffer reaches that minimum size (Nagle algorithm).

I do not have this 200ms extra delay when using the same socket without SSH activated.

Possible solutions are:
1) increase packet size (with stuffing bytes) to this minumum so underlying buffer always reaches that minimum size

2) Set NODELAY option on socket so the Nagle algorithm does not get involved

I plan to use 1) for binary data.
I have used solution 2) for commands:

BOOL disabled = TRUE;
// Make sure delay for small packets is removed
setsockopt((SOCKET)ClientSocket->Socket->SocketHandle, IPPROTO_TCP, TCP_NODELAY,
(char*)&disabled, sizeof(BOOL));

I checked that NODELAY was set to true with getsockopt().
Even though I do not see any improvement.

Is there any option in TScSSHClient and TScSSHChannel instances that would prevent this improvement ?

Thanks

I did not fully understand what you mean? How do you use TClientSocket as a underlying socket - do you rewrite functionality inside SecureBridge by yourself? If yes, what functionality do you need in SecureBridge in the current implementation?

SecureBridge sets the TCP_NODELAY option for any created socket.

The TClientSocket instance uses host and port of the SSHChannel.
It looks that it is the server side which does not set the TCP_NODELAY option, and it is the server options which are predominant.
My question was just to know if SecureBridge classes exposed that property/option in some way or if it was just at the socket level.
I do not rewrite any SecureBridge code.

I cannot reproduce the described behaviour with socket delay and therefore cannot advice any solution.
Can you compose a small sample to demonstrate the problem and send it to dmitryg*devart*com?

Server part is running under VxWorks so I believe it is more on this side that the problem resides.
I just wanted to make sure that it was not on the client side (using SecureBridge framework) that some options were causing this behavior.

I have not tested with a server coded with SecureBridge framework yet.

The problem was solved by using a fixed packet size (2048 bytes) to make sure the Naggle algorithm does get in the way. It was responsible for delaying small packets sending through buffering. Both client and server where modified.