Asynchronous Sockets
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:
- Socket read.
- Socket write.
- Connect to remote hostname:port
- Accept connection from client
- 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.