Async Methods in .NET

Yesterday I had to rewrite some C# code at work. We were trying to send a message to a webserver without waiting for a response, but for some reason it would hang after only sending a couple messages. I ended up rewriting it to use asynchronous sockets instead of the WebRequest class.

After I had it working, I realized that while the Begin/End pattern that .NET uses for asynchronous operations is better than not having any asychronous ability at all, it would be even better if it had some kind of syntactic support for this, instead of using callback methods.

Here's the code I ended up writing, using callbacks:

    public void log (LogEntry entry) {
        string logString = logEntryToString(entry);
        try {
            Socket s = new Socket(AddressFamily.InterNetwork,
                SocketType.Stream, ProtocolType.Tcp);
            IPAddress ipAddr = Dns.Resolve(m_host).AddressList[0];
            s.BeginConnect(new IPEndPoint(ipAddr, m_port),
                new AsyncCallback(this.finishAsyncLog),
                new Pair(s, logString));
        }
        catch (Exception e) {
            throw new LogException("Problem connecting to log server: "+
                e.Message + " (Log entry: " + logString + ")");
        }
    }

    private void finishAsyncLog(IAsyncResult result) {
        Pair state = (Pair)result.AsyncState;
        Socket s = (Socket)state.First;
        string logString = (string)state.Second;

        try {
            s.EndConnect(result);

            string encodedString = "/log?pairs=" +
                System.Web.HttpUtility.UrlEncode(logString,
                new UTF8Encoding(false));

            string httpRequest = "GET /log?" + logString + "\r\n\r\n";
            Byte[] ByteGet = Encoding.ASCII.GetBytes(httpRequest);
            s.Send(ByteGet, ByteGet.Length, SocketFlags.None);

            s.Close();
        }
        catch (Exception e) {
            Console.WriteLine("Problem connecting to log server: "+
                e.Message + " (Log entry: " + logString + ")");
        }
    }

Notice how I had to break the log() method into two pieces -- one to start the asynchronous operation, and one to finish it. I also had to bundle up a couple local variables into a Pair object, so that I could pass both of them to the callback method (which only takes one state object). If C# and .NET had been designed with some kind of fork or coroutine or continuation facility, the code might have looked more like this:

    public void log (LogEntry entry) {
        string logString = logEntryToString(entry);
        try {
            Socket s = new Socket(AddressFamily.InterNetwork,
                SocketType.Stream, ProtocolType.Tcp);
            IPAddress ipAddr = Dns.Resolve(m_host).AddressList[0];
            IPEndPoint ep = new IPEndPoint(ipAddr, m_port);
            callAsync(s.Connect(ep)) {
                string encodedString = "/log?pairs=" +
                    System.Web.HttpUtility.UrlEncode(logString,
                    new UTF8Encoding(false));
                string httpRequest = "GET " + encodedString + "\r\n\r\n";
                Byte[] ByteGet = Encoding.ASCII.GetBytes(httpRequest);
                s.Send(ByteGet, ByteGet.Length, SocketFlags.None);

                s.Close();
            }
        }
        catch (Exception e) {
            throw new LogException("Problem connecting to log server: "+
                e.Message + " (Log entry: " + logString + ")");
        }
    }

This would be much cleaner -- it's only one method instead of two and I don't have to do any games to package up my local variables. But it does have the drawback of not making it clear that after the socket is connected, the code will be running in a different thread than it started in. It's also not clear whether the catch should apply to the asynchronous code or not. So I suppose it was the right decision for the designers of .NET to use callbacks, but it's still unfortunate that we couldn't have had a more sophisticated solution.

Posted on August 28, 2003 10:50 AM
More languages articles