SoSndBuf and SoRcvBuf Properties

Beginning with Chilkat v9.4.0, two new TCP socket performance properties, SoSndBuf and SoRcvBuf, will be added to each of the following Chilkat components/libs: FTP2, HTTP, SFTP, SSH, SshTunnel, IMAP, and MailMan (POP3/SMTP).

These properties allow for the underlying socket’s send and receive buffer sizes to be set. These are socket options associated with the setsockopt system call (see http://linux.die.net/man/2/setsockopt ) using the SO_SNDBUF and SO_RCVBUF options.

It is recommended that these socket options remain unchanged unless performance seems slow. If uploads seems slow, then set the SoSndBuf to a larger buffer size. It is recommended to use buffer sizes that are a multiple of 4096. The default buffer size varies from system to system. To get the value, examine the LastErrorText property after calling any Chilkat method that establishes a TCP connection. The socket’s send and receive buffer sizes will be reported.

Likewise, if downloads seem slow, set the SoRcvBuf to a larger value.

For more information about TCP performance, see these web pages:

http://onlamp.com/pub/a/onlamp/2005/11/17/tcp_tuning.html

http://smallvoid.com/article/winnt-winsock-buffer.html

http://www.ibm.com/developerworks/linux/library/l-hisock/index.html

Improving MHT Download Performance with Caching

Question:
I’m spidering search results and trying to archive hundreds of pages to MHT’s.  I’m testing your control and found it much slower than Internet Explorer. Also, while I’m not doing this now, is this control threadsafe if I ever wanted to try that to improve performance?

Answer:

Internet Explorer is faster because it uses multiple threads, and because it uses disk caching.  Both can be accomplished using Chilkat MHT.

First, the easy answer:  Yes, the MHT component/library is thread-safe.  Of course, each thread should use it’s own instance of an MHT object.  Also, the disk-caching is thread-safe.  Multiple threads can be updating files in the same caching directory without interfering with each other.

Implementing disk caching with MHT is easy.  It’s simply a matter of setting a few properties and telling the component the path of the cache directory.  Here are examples:

ASP: Download Web Page to MHT with w/ Disk Cache

SQL Server: Download Web Page to MHT with w/ Disk Cache

C#: Download Web Page to MHT with w/ Disk Cache

C++: Download Web Page to MHT with w/ Disk Cache

MFC: Download Web Page to MHT with w/ Disk Cache

C: Download Web Page to MHT with w/ Disk Cache

Delphi: Download Web Page to MHT with w/ Disk Cache

Visual FoxPro: Download Web Page to MHT with w/ Disk Cache

Java: Download Web Page to MHT with w/ Disk Cache

Perl: Download Web Page to MHT with w/ Disk Cache

PHP: Download Web Page to MHT with w/ Disk Cache

Python: Download Web Page to MHT with w/ Disk Cache

Ruby: Download Web Page to MHT with w/ Disk Cache

VB.NET: Download Web Page to MHT with w/ Disk Cache

Visual Basic: Download Web Page to MHT with w/ Disk Cache

VBScript: Download Web Page to MHT with w/ Disk Cache

FTP Upload Speed

Question:

We’re rather puzzled by what appears to be capped speeds on uploads,
despite no cap being set. Testing uploads, we’re seeing about 350
KB/s via the Ck library to our (local network) FTP server. A
FileZilla transfer of the same file to the same server can happily hit
up to 7MB/s.

I realize Ck supports bandwidth throttling, but those values are at
their default value of 0.

I’ve attached the relevant test code. There is one test file that
gets uploaded first, then we loop over an array of files. The first
file is tiny, then there’s a larger file (usually 20mb+), and on that
I see the ~350KB/s speeds.

Is this a familiar problem? Any known solutions, workarounds or
diagnostics you can suggest?

Answer:

Try setting the SendBufferSize property to a larger value. Perhaps
1MB instead of the default 64K.

Customer Response:

Thanks – that was the problem. Even with 512k buffers, I can happily max
out our local bandwidth.

Note: The default value for the SendBufferSize property will be change to 512K. This change will be documented in the release notes when the new version is available, as well as in the online documentation.