The latest version of the Chilkat HTTP component introduces a set of methods and properties that allow already-existing methods to be called asynchronously. For example, by setting the UseBgThread property equal to True, any background-enabled method, such as Download, will run in a background thread. Normally, when called synchronously, the method returns control to the caller only after the HTTP operation has completed. However, when UseBgThread = True, the method returns immediately and the HTTP operation is started in a background thread. (For a given HTTP object instance, only one background method may be ongoing at a time. It is possible to use multiple HTTP object instances, each of which might be processing a backgrounded method call.)

The set of background-enabling methods and properties are:

• (property) UseBgThread - If True, then background-enabled methods will run in a background thread. Normally, a method will return after its work is completed. However, when UseBgThread is true, the method will return immediately and a background thread is started to carry out the method’s task.
• (property) BgTaskRunning - If True then the object instance already has a backgrounded method running. Another backgrounded method cannot be started until the 1st completes. (Multiple simultaneous background methods may run by using multiple object instances.)
• (property) BgTaskFinished - Becomes True when the background method completes. Your application would periodically check for this condition.
• (property) BgTaskSuccess - Only meaningful (True/False) after a background method completes.
• (property) BgLastErrorText - Last-error information is saved here and not in the LastErrorText property. If the background method fails, this will contain information about what transpired. (This property also contains information when the background method succeeds.)
• (method) BgTaskAbort - Call this to force the currently running backgrounded method to abort.
• (property) BgResultString - If the backgrounded method returns a string, the return value is found here.
• (property) BgResultInt - If the backgrounded method returns an integer, the return value is found here.
• (property) BgResultData - If the backgrounded method returns a byte array, the returned data is found here.
• (method) BgResponseObject - If the backgrounded method returns an HttpResponse object, it may be retrieved by calling this method.

Example
An example of backgrounding the Download method may be found here.

Background Enabling other Chilkat Components
The HTTP component is the first Chilkat component to become background-enabled. The current development plan is to add the identical set of properties and methods to other Chilkat components to background-enable its functionality (such as for POP3, SMTP, IMAP, SSH, SFTP, Zip, MHT, etc.)

The following example demonstrates the new asynchronous HTTP functionality (in the latest version of Chilkat) that allows for any HTTP method to be run asynchronously in a background thread:

ASP: HTTP in a Background Thread (Asynchronous HTTP)
SQL Server: HTTP in a Background Thread (Asynchronous HTTP)
C#: HTTP in a Background Thread (Asynchronous HTTP)
C++: HTTP in a Background Thread (Asynchronous HTTP)
MFC: HTTP in a Background Thread (Asynchronous HTTP)
C: HTTP in a Background Thread (Asynchronous HTTP)
Delphi: HTTP in a Background Thread (Asynchronous HTTP)
Visual FoxPro: HTTP in a Background Thread (Asynchronous HTTP)
Java: HTTP in a Background Thread (Asynchronous HTTP)
Perl: HTTP in a Background Thread (Asynchronous HTTP)
PHP: HTTP in a Background Thread (Asynchronous HTTP)
Python: HTTP in a Background Thread (Asynchronous HTTP)
Ruby: HTTP in a Background Thread (Asynchronous HTTP)
VB.NET: HTTP in a Background Thread (Asynchronous HTTP)
Visual Basic: HTTP in a Background Thread (Asynchronous HTTP)
VBScript: HTTP in a Background Thread (Asynchronous HTTP)

This blog post is an attempt to explain the concepts of asynchronous socket programming using the Chilkat Socket class/component.   There are five types of socket operations that may occur asynchronously:

1. Socket read.
2. Socket write.
3. Connect to remote hostname:port
4. Accept connection from client
5. DNS lookup

A synchronous socket operation is easy to understand.  If you call ReceiveBytes, the method returns only after it has received data on the socket.  If you call Connect, the method returns only after a connection has been established.  If you call AcceptNextConnection, the method returns after an incoming connection has arrived and has been accepted.

Asynchronous methods allow your application to start a socket operation in a background thread.  Your application is then free to do other things while the background thread is working on the socket operation.  For example, your application might do database queries, or update the user interface, etc.  Your application can periodically check to see if the asynchronous operation has completed.  It does this by checking a component property such as AsyncReceivedFinished, AsyncSendFinished, AsyncAcceptFinished, etc.  When the socket operation is finished, your application can get the status via properties such as AsyncReceiveSuccess, AsyncSendSuccess, etc.  Other properties provide the data recieved or the socket object for an accepted connection.

IMPORTANT:  The purpose of the asynchronous socket methods is NOT for queueing up a bunch of socket operations.  For example, if your application calls AsyncReceiveString to initiate a socket receive operation in the background, you cannot call AsyncReceiveString again until the first asynchronous receive completes.   But think about it:  Why would you have more than one asynchronous read oustanding at a time on the same socket?  It doesn’t really make sense.  If Chilkat were to automatically start another read, where would the data go?  When an AsyncReceiveString completes, the received string is available in the AsyncReceivedString property.  Your application can capture or use the received data and initiate the next asynchronous read.  (You may say: “But I want my application to continue reading for performance reasons.”  The answer is:  The operating system is already doing that for you in the background.  The operating system manages connected sockets.  When you receive data on a socket, in most cases you’re simply getting the data that the underlying operating system has already received and has waiting for the application in the underlying socket buffers.)

Regarding asynchronous sending:  Don’t forget that the operating system buffers socket operations.  Unless the outgoing OS buffers are full, or the amount of data you’re sending in a single call is very large, a synchronous send will more-or-less return immediately.  (Did you ever notice when using an FTP program such as WS-FTP, or CuteFTP, that when you upload a file to an FTP server, the upload begins very quickly but then slows down?  It’s because the first amounts of data sent on the socket are buffered by the OS.  The “send” completes while the operating system continues to work (in the background) to send the data in the outgoing socket buffer.  The application is free to continue (in other words, the operating system says “thanks, I have the data and I’ll send it, you may continue with what you’re doing”.)  A socket send operation will only block when the underlying socket send buffers are full.

Back to the main point:  Your application cannot start another asynchronous send operation until the outstanding send completes.  The same goes for Connect and Accept operations.

IMPORTANT:  The Chilkat Socket component is full-duplex, which means:  You may have simultaneous asynchronous receive, send, connect, and accept operations.   You cannot start more than one asynchronous operation of the same type.  For example, if you start an asynchronous receive, you may also start an asynchronous send even though the asynchronous read has not yet completed.