Alxandr Productions

dotRant: Making an IRC library for .NET in C# – Part 5: Reflection and IRCCommands

Alxandr — Fri, 04 Nov 2011 07:33:06 +0000

Last post we discussed methods of responding to messages coming from the IRC-server, and I also explained the method I wanted to use, and why I would want to use it. Today I will do the actual implementation of the described method. Also, to handle IRC commands, we need to parse them, and we need a method of sending replies to the server, and last but not least we need to create the attribute to be set on the methods that we want called. But lets start with the first thing first:

Parsing IRC-commands

As discuss earlier, an IRC-command consists of mainly 3 parts, a prefix, a name, and a list of parameters. Before we can do anything we need to split the command up into these three parts so that we know what command is actually send, and by whom, and we need to create a data-structure to hold this data. For this we will create the IRCCommand class.

    /// 
    /// A class used to represent IRC commands.
    /// 
    [DebuggerDisplay("{ToString()}", Name = "{Name}")]
    public class IrcCommand
    {
        private string name;
        private string prefix;
        private IrcParameter[] parameters;

        /// 
        /// Initializes a new instance of the  class.
        /// 
        /// The prefix.
        /// The name.
        /// The parameters.
        public IrcCommand(string prefix, string name, params IrcParameter[] parameters)
        {
            this.prefix = prefix;
            this.name = name;
            this.parameters = parameters;

            var restParams = parameters.Where(p => p.IsRest);
            if (restParams.Count() > 1)
                throw new ArgumentException("Can't be more than 1 rest-parameter.", "parameters");
            else if (restParams.Count() == 1 && restParams.First() != parameters.Last())
                throw new ArgumentException("Rest parameter must always be the last parameter.", "parameters");
        }

        /// 
        /// Gets the name.
        /// 
        public string Name
        {
            get { return name; }
        }

        /// 
        /// Gets the prefix.
        /// 
        public string Prefix
        {
            get { return prefix; }
        }

        /// 
        /// Gets the parameters.
        /// 
        public string[] Parameters
        {
            get { return parameters.Select(p => (string)p).ToArray(); }
        }

        /// 
        /// Returns a  that represents this instance.
        /// 
        /// 
        /// A  that represents this instance.
        /// 
        public override string ToString()
        {
            return (prefix == null ? "" : ":" + prefix + " ") +
                name + " " + String.Join(" ", parameters.Select(p => p.ToString()));
        }
    }

    /// 
    /// Represent an IRC-parameter.
    /// 
    [DebuggerDisplay("{ToString()}")]
    public class IrcParameter
    {
        string value;
        bool isRest;

        /// 
        /// Initializes a new instance of the  class.
        /// 
        /// The value.
        /// if set to true [is rest].
        public IrcParameter(string value, bool isRest = false)
        {
            this.value = value;
            this.isRest = isRest;

            if (!isRest && value.IndexOfAny(new char[] { '\0', '\n', '\r', ' ' }) != -1)
                throw new ArgumentException("value can't contain '\\0', '\\n', '\\r' or ' ' in a non-rest-parameter.", "value");
        }

        /// 
        /// Gets the value.
        /// 
        public string Value
        {
            get { return value; }
        }

        /// 
        /// Gets a value indicating whether this instance is rest-value.
        /// 
        /// 
        ///   true if this instance is rest-value; otherwise, false.
        /// 
        public bool IsRest
        {
            get { return isRest; }
        }

        /// 
        /// Performs an implicit conversion from  to .
        /// 
        /// The parameter.
        /// 
        /// The result of the conversion.
        /// 
        public static implicit operator IrcParameter(string parameter)
        {
            return new IrcParameter(parameter);
        }

        /// 
        /// Performs an explicit conversion from  to .
        /// 
        /// The parameter.
        /// 
        /// The result of the conversion.
        /// 
        public static explicit operator string(IrcParameter parameter)
        {
            return parameter.value;
        }

        /// 
        /// Returns a  that represents this instance.
        /// 
        /// 
        /// A  that represents this instance.
        /// 
        public override string ToString()
        {
            return (isRest ? ":" : "") + value;
        }
    }

These are two fairly simple classes which don’t do much more than hold the data required, also, the IrcParameter contains conversion to and from string using implicit and explicit operators. Also, the constructor for both classes performs checks as to the validity of the data given. The only thing left to do here is to add parsing of the commands, but before we do that, let’s take a look at how the commands are defined in the IRC specification (RFC 2812):
PS: Please do note that what I here refer to as a command, is referred to as a message in this specification.

    message    =  [ ":" prefix SPACE ] command [ params ] crlf
    prefix     =  servername / ( nickname [ [ "!" user ] "@" host ] )
    command    =  1*letter / 3digit
    params     =  *14( SPACE middle ) [ SPACE ":" trailing ]
               =/ 14( SPACE middle ) [ SPACE [ ":" ] trailing ]

    nospcrlfcl =  %x01-09 / %x0B-0C / %x0E-1F / %x21-39 / %x3B-FF
                    ; any octet except NUL, CR, LF, " " and ":"
    middle     =  nospcrlfcl *( ":" / nospcrlfcl )
    trailing   =  *( ":" / " " / nospcrlfcl )

    SPACE      =  %x20        ; space character
    crlf       =  %x0D %x0A   ; "carriage return" "linefeed"

Normally, IRC-commands are really simple. They’ve split by space and have a prefix, however, when reading the specification it becomes clear that they can be much more complex looking then that. For instance, parameters that are not “trailing” (or as I’ve called them, rest-parameters) can contain ‘:’, they just can’t start with a colon. This means we can’t just simply split on ‘:’ to get rest-parameters, neither can we simply split on space, cause spaces needs to be maintained in the rest-parameter. Nevertheless, it’s not a very complex thing to parse, as you will soon see.

A thing to notice first, is that you can have messages without a prefix, and that if there is a prefix, the command should start with a colon. This can be checked easily by doing something like this:

        /// 
        /// Parses the specified command.
        /// 
        /// The command.
        /// The IrcCommand-representation of the given command.
        public static IrcCommand Parse(string cmd)
        {
            string prefix = null, name = null;
            List parameters = new List();
            if (cmd[0] == ':')
            {
                prefix = cmd.Substring(1, cmd.IndexOf(' ') - 1);
                cmd = cmd.Substring(cmd.IndexOf(' ') + 1);
            }

After that, we need to get the name of the command, which too is really simple, and can be achieved with the following 3 lines:

            var nameEnd = cmd.IndexOf(' ');
            name = cmd.Substring(0, nameEnd);
            cmd = cmd.Substring(nameEnd + 1);

Then, what’s left is the parameters, and the rules for parameters is that if they start with a space, it’s a rest-parameter, and there can only be one of them, thus the code can look like this:

            while (cmd.Length > 0)
            {
                if (cmd[0] == ':')
                {
                    parameters.Add(cmd.Substring(1).AsIrcRestParameter());
                    cmd = "";
                }
                else
                {
                    var paramEnd = cmd.IndexOf(' ');
                    if (paramEnd == -1)
                        paramEnd = cmd.Length;
                    var param = cmd.Substring(0, paramEnd);
                    parameters.Add(param);
                    if (paramEnd != cmd.Length)
                        cmd = cmd.Substring(paramEnd + 1);
                    else
                        cmd = "";
                }
            }

            return new IrcCommand(prefix, name, parameters.ToArray());
        }

For the following code to work we need to add an extension-method to System.String that turns it into an IRC rest-parameter. I’ve added 2 excension-methods to help with this in the following helper-class:

    /// 
    /// Provides extension-helpers for IrcParameters.
    /// 
    public static class IrcParameterExtensions
    {
        /// 
        /// Converts the string to an irc parameter.
        /// 
        /// The parameter.
        /// if set to true treated as rest-parameter, if false not treated as rest-parameter, and if null selects automatically.
        /// A irc parameter.
        public static IrcParameter AsIrcParameter(this string parameter, bool? isRest = null)
        {
            return new IrcParameter(parameter, isRest.HasValue ? isRest.Value : parameter.IndexOfAny(new char[] { '\0', '\n', '\r', ' ', ':' }) != -1);
        }

        /// 
        /// Converts the string to an irc parameter.
        /// 
        /// The parameter.
        /// A irc rest-parameter.
        public static IrcParameter AsIrcRestParameter(this string parameter)
        {
            return new IrcParameter(parameter, true);
        }
    }

And there you have it. That’s all that’s required for parsing IRC-commands. As said, IRC is a rather simple protocol. Now we got more or less everything we need to start responding to commands that are sent from the server.

Handling commands

In order to actually handle commands sent from the server it’s needed to tell our class what functions it should trigger for what commands, and in order to do that I decided to use attributes as explained in the previous post. But in order to do so, we first need to actually create the attribute-class. All attribute-classes needs to inherit from Attribute, and they can have an AttributeUsageAttribute to denote where and how you can use the attribute. The attribute we are to create is fairly simple. All it requires is a name and the ability to later retrieve that name, and can be written like this:

    /// 
    /// Attribute used to denote IrcCommand-methods
    /// 
    [AttributeUsage(AttributeTargets.Method, AllowMultiple = true)]
    public class IrcCommandAttribute : Attribute
    {
        private string name;
        /// 
        /// Initializes a new instance of the  class with a name.
        /// 
        /// The name.
        public IrcCommandAttribute(string name)
        {
            this.name = name;
        }

        /// 
        /// Gets the name.
        /// 
        public string Name
        {
            get { return name; }
        }
    }

Now we’re all set. Let’s start by updating the client_Message method in our IrcClient class to look like this:

        void client_Message(object sender, MessageEventArgs e)
        {
            string msg = encoding.GetString(e.Message);
            var cmd = IrcCommand.Parse(msg);
            GetCommand(cmd.Name).Invoke(this, new object[] { cmd.Prefix, cmd.Name, cmd.Parameters });
        }

Pretty slick, eh? Anyways, with this added we need to create the GetCommand(string name) method, but first I’d like to talk a bit about the strategy we take here. As explained in the previous post I aim to use the DefaultDictionary to store references from name to function-call and thus we need to populate a DefaultDictionary somewhere. However, consider a scenario where you have more than a 100 IrcClient instances running at once. There is no need for each of them to have their own DefaultDictionary cause they all have the same methods, thus we can make it static. This saves both memory, and initialization-time of our class since we only need to build the dictionary once. However, there is one problem with this approach too, and that is if you subclass the IrcClient. If you do so you can get various funny effects like the application not doing what you want it to, or simply just crashing. To prevent this we need a double-dictionary that maintains a DefaultDictionary for each type of IrcClient we currently have. Like this:

private static readonly Dictionary> ircCommands = new Dictionary>();

The rest is pretty straight forward. When you call the GetCommand(string name) method it calls a static GetCommand(Type type, string name) method that checks if the type is present in the first dictionary. If it’s not it creates a new DefaultDictionary for that type. After that it returns the MethodInfo for the method to call regardless if the DefaultDictionary was just created or not. To create the DefaultDictionary I employ a simple LINQ-trick and all in all we end up with this:

        private static MethodInfo GetCommand(Type type, string cmdName)
        {
            if (!ircCommands.ContainsKey(type))
            {
                lock (ircCommands)
                {
                    if (!ircCommands.ContainsKey(type))
                    {
                        var dict = new DefaultDictionary();
                        var methods = from mi in type.GetMethods(BindingFlags.Public | BindingFlags.NonPublic | BindingFlags.Instance | BindingFlags.InvokeMethod)
                                      from attr in mi.GetCustomAttributes(typeof(IrcCommandAttribute), true).Cast()
                                      select new { Method = mi, Name = attr.Name };
                        foreach (var m in methods)
                        {
                            if (m.Name != "_Default")
                                dict[m.Name] = m.Method;
                            else
                                dict.Default = m.Method;
                        }
                        ircCommands.Add(type, dict);
                    }
                }
            }
            return ircCommands[type][cmdName];
        }
        private MethodInfo GetCommand(string cmdName) { return GetCommand(this.GetType(), cmdName); }

After that we can go ahead and add a couple of methods to our class. Just to clarify things I prefix these methods with IrcCmd_.
I know these comments makes no sence, but I didn’t notice at the time of writing the code. The comments are auto-generated.

        /// 
        /// Ircs the CMD_ default.
        /// 
        /// The prefix.
        /// The CMD.
        /// The parameters.
        [IrcCommand("_Default")]
        protected virtual void IrcCmd_Default(string prefix, string cmd, string[] parameters)
        {
            //TODO: Create and fire an event.
        }

        /// 
        /// Ircs the CMD_ ping.
        /// 
        /// The prefix.
        /// The CMD.
        /// The parameters.
        [IrcCommand("PING")]
        protected virtual void IrcCmd_Ping(string prefix, string cmd, string[] parameters)
        {
            Send(new IrcCommand(null, "PONG", parameters[0].AsIrcParameter()));
        }

Small changes

I’ve changed a few things about the IrcClient class since my last post, and the main thing that’s changed is the constructor. I removed the parameters from the constructor and rather made them into properties instead, so the constructor now looks like this:

        /// 
        /// Initializes a new instance of the  class.
        /// 
        public IrcClient()
        {
            if (encoding == null)
                encoding = Encoding.UTF8;

            client = new MessageConnection();
            client.Disconnect += new EventHandler(client_Disconnect);
            client.SslValidate += new EventHandler(client_SslValidate);
            client.Message += new EventHandler(client_Message);
        }

And also I’ve added 3 new properties that looks like this:

        /// 
        /// Gets or sets the encoding.
        /// 
        /// 
        /// The encoding.
        /// 
        public Encoding Encoding
        {
            get
            {
                return encoding;
            }
            set
            {
                encoding = value;
            }
        }

        /// 
        /// Gets or sets the nick.
        /// 
        /// 
        /// The nick.
        /// 
        public string Nick
        {
            get
            {
                return nick;
            }
            set
            {
                nick = value;
                if (Connected)
                    Send(new IrcCommand(null, "NICK", nick));
            }
        }

        /// 
        /// Gets or sets the full name.
        /// 
        /// 
        /// The full name.
        /// 
        public string FullName
        {
            get
            {
                return fullName;
            }
            set
            {
                if (Connected)
                    throw new InvalidOperationException("Can't change full-name after connected.");
                fullName = value;
            }
        }

Then there’s the ConnectAsync method that now looks like this:

        public Task ConnectAsync(string hostname, int port, bool secureConnection)
        {
            if (String.IsNullOrWhiteSpace(nick))
                throw new InvalidOperationException("Can't connect with nick beeing unset.");
            if (String.IsNullOrWhiteSpace(fullName))
                throw new InvalidOperationException("Can't connect with fullname beeing unset.");
            return client.ConnectAsync(hostname, port, secureConnection).ContinueWith(task =>
            {
                Send(new IrcCommand(null, "PASS", "*"));
                Send(new IrcCommand(null, "NICK", nick));
                Send(new IrcCommand(null, "USER", "dotRant", "8", "*", fullName.AsIrcRestParameter()));
                // PASS *
                // NICK 
                // USER dotRant 8 * :
            });
        }

And last but not least the Send-method:

        private void Send(IrcCommand cmd)
        {
            var bytes = encoding.GetBytes(cmd.ToString());
            client.Send(bytes);
        }

As always, if there are any questions, please leave a comment below. The code for this post can be found here: https://github.com/Alxandr/dotRant/tree/part-5/src/dotRant.

Until then. Alxandr.

dotRant: Making an IRC library for .NET in C# – Part 4: Skeletal structure of the IrcClient and the DefaultDictionary

Alxandr — Mon, 24 Oct 2011 21:42:52 +0000

In the previous post in this series I talked about some errors I found in the dotRant code, and what had to be done to fix those, and I also talked a bit about taking an async approach to connecting to the server. This will allow for better responsiveness in applications using dotRant while still maintaining a simple way of using the library tanks to the System.Threading.Tasks namespace. In this post I will create the actual base structure of the IrcClient-class, and also construct a helper-class that I call DefaultDictionary, but first of all, let’s take a look at the problem we have at hand.

Irc consists of messages (or as I like to call them, commands) sent back and forth from client and server. These messages all contains a name which can be viewed as a string (though it might just be a number). We’ve already made functionality for sending and receiving these messages, however, we need to act upon the fact that there is a new command available, and depending upon how we decide to do this our class might end up as a mess, or it might end up being neat and tidy. I don’t think I have to tell you that I don’t want the class to end up as a mess, so let’s look at some of the alternative ways of handling commands sent from the server.

Handling commands

The first thing that comes to mind when you need to run different code depending on something is a regular if-else-test. Using an if-else-test we can write a function that handles the command like this:

private void HandleCommand(string cmdName, string[] cmdArgs)
{
	if(cmdName == "PRIVMSG")
	{
		// Perform handeling of the private message.
	}
	else if(cmdName == "JOIN")
	{
		// Perform handeling of a JOIN command.
	}
	else
	{
		// Default action, command not known.
	}
}

Needless to say, this is not very pretty, and does scale bad. You end up putting all the functionality into a single function, and there is a lot of code to do this simple matching. One way we can make this code better is by changing the if-else-test with a switch-test. Another thing we can do to further improve our code is to create functions for the commands, rather than just putting all the code in one function, then we end up with something like this:

private void HandleCommand(string cmdName, string[] cmdArgs)
{
	switch(cmdName)
	{
		case "PRIVMSG":
			HandlePrivmsg(cmdName, cmdArgs); break;
		case "JOIN":
			HandleJoin(cmdName, cmdArgs); break;
		default:
			HandleUnknown(cmdName, cmdArgs); break;
	}
}

This makes our code a lot better, but there is still one problem, whenever we add support for a new command we need to change code two places. First, we need to create a new function, than we need to add a clause in our switch-case statement, and if we remove something, or rename, it also needs to be changed both places. I personally don’t like that, and thus has found another way to solve this problem, by using Attributes. If you don’t know what attributes in C# is I recommend reading up on them, but essentially you can add info to functions or properties or even input-parameters and classes that you might use later to figure out how to use that class or method, and that’s precisely what we’re going to do. On our HandleJoin-method (which by the way is not necessarily a final name as I have yet to write the method) we just denote that we want this method to be called whenever a “JOIN” command is received, and then we handle the rest in our HandleCommand method (which too is just a temporarily name). Doing this enables us to add functionality much more simply, but how do we achieve this? Well, the actual implementation is something I’ll post in my next blog-post as I still need to do a bit more research about how efficient my current method of handling that task is. However, one of the things we do require for this functionality is to emulate the switch-case statement over a variable list of items containing a name and a function to call should there be a match, and also a default item, and for this I’ve created the DefaultDictionary. The DefaultDictionary is basically just a simple Dictionary that has a Default property that is returned should the dictionary not contain a match for the requested key, just like the switch-case does. Thus, you will never get a KeyNotFoundException cause if the key is not found the Default is returned instead. The DefaultDictionary is really easy to implement, and should be easy to understand. The code, fully commented with XML-comments where required, looks like this:

    /// 
    /// A dictionary that also holds a default-value which it returns if
    /// you try to access a key that doesn't exist.
    /// 
    /// The type of the key.
    /// The type of the values.
    public class DefaultDictionary : IDictionary
    {
        private TValue defaultValue = default(TValue);
        private Dictionary dict = new Dictionary();

        /// 
        /// Gets or sets the default.
        /// 
        /// 
        /// The default.
        /// 
        public TValue Default
        {
            get { return defaultValue; }
            set { defaultValue = value; }
        }

        #region IDictionary Members

        /// 
        /// Gets or sets the value associated with the specified key.
        /// 
        /// The key of the value to get or set.
        /// The value associated with the specified key.
        ///  is null.
        /// The property is set and the  is read-only.
        public TValue this[TKey key]
        {
            get
            {
                if (!dict.ContainsKey(key))
                    return defaultValue;
                return dict[key];
            }
            set
            {
                dict[key] = value;
            }
        }

        /// 
        /// Adds an element with the provided key and value to the .
        /// 
        /// The object to use as the key of the element to add.
        /// The object to use as the value of the element to add.
        ///  is null.
        /// An element with the same key already exists in the .
        /// The  is read-only.
        public void Add(TKey key, TValue value)
        {
            dict.Add(key, value);
        }

        /// 
        /// Determines whether the  contains an element with the specified key.
        /// 
        /// The key to locate in the .
        /// 
        /// true if the  contains an element with the key; otherwise, false.
        /// 
        ///  is null.
        public bool ContainsKey(TKey key)
        {
            return dict.ContainsKey(key);
        }

        /// 
        /// Gets an  containing the keys of the .
        /// 
        /// An  containing the keys of the object that implements .
        public ICollection Keys
        {
            get { return dict.Keys; }
        }

        /// 
        /// Removes the element with the specified key from the .
        /// 
        /// The key of the element to remove.
        /// 
        /// true if the element is successfully removed; otherwise, false.  This method also returns false if  was not found in the original .
        /// 
        ///  is null.
        /// The  is read-only.
        public bool Remove(TKey key)
        {
            return dict.Remove(key);
        }

        /// 
        /// Gets the value associated with the specified key.
        /// 
        /// The key whose value to get.
        /// When this method returns, the value associated with the specified key, if the key is found; otherwise, the default value for the type of the  parameter. This parameter is passed uninitialized.
        /// 
        /// true if the object that implements  contains an element with the specified key; otherwise, false.
        /// 
        ///  is null.
        public bool TryGetValue(TKey key, out TValue value)
        {
            return dict.TryGetValue(key, out value);
        }

        /// 
        /// Gets an  containing the values in the .
        /// 
        /// An  containing the values in the object that implements .
        public ICollection Values
        {
            get { return dict.Values; }
        }

        /// 
        /// Removes all items from the .
        /// 
        /// The  is read-only. 
        public void Clear()
        {
            dict.Clear();
        }

        #endregion

        #region ICollection> Members

        void ICollection>.Add(KeyValuePair item)
        {
            ((ICollection>)dict).Add(item);
        }

        void ICollection>.Clear()
        {
            ((ICollection>)dict).Clear();
        }

        bool ICollection>.Contains(KeyValuePair item)
        {
            return ((ICollection>)dict).Contains(item);
        }

        void ICollection>.CopyTo(KeyValuePair[] array, int arrayIndex)
        {
            ((ICollection>)dict).CopyTo(array, arrayIndex);
        }

        int ICollection>.Count
        {
            get { return ((ICollection>)dict).Count; }
        }

        bool ICollection>.IsReadOnly
        {
            get { return ((ICollection>)dict).IsReadOnly; }
        }

        bool ICollection>.Remove(KeyValuePair item)
        {
            return ((ICollection>)dict).Remove(item);
        }

        #endregion

        #region IEnumerable> Members

        IEnumerator> IEnumerable>.GetEnumerator()
        {
            return ((IEnumerable>)dict).GetEnumerator();
        }

        #endregion

        #region IEnumerable Members

        IEnumerator IEnumerable.GetEnumerator()
        {
            return ((IEnumerable)dict).GetEnumerator();
        }

        #endregion
    }

As you can see it just delegates every call to the underlying dictionary, with the exception of the index-method where it returns the defaultValue if the key does not exist. The DefaultDictionary is used to store the function-delegates associated with their names, and a default-action to perform should the command not be known. As we get further on you will also see that the DefualtDictionary is useful for other aspects of the irc-library too.

The skeletal structure of the IrcClient

Now it’s about time we start writing the actual IrcClient-class. The IrcClass needs to delegate the events fired by the MessageConnection with the exception of the MessageEvent, it should contain Connect and ConnectAsync methods, and it must allow the user of the library to select Encoding to be used, and Nick and Fullname of the connected user (also, at a later point I will add the functionality to specify the client-name by subclassing the IrcClient-class. All in all it’s a simple class, so I’m just going ahead and posting the code as most of it’s been explained earlier.

    /// 
    /// An IRC-client used to connect to and chat at a irc-network.
    /// 
    public class IrcClient
    {
        private static Logger logger = LogManager.GetCurrentClassLogger();

        #region Private Members
        private readonly MessageConnection client;
        private Encoding encoding;
        private string nick;
        private string fullName;
        #endregion

        #region Constructors
        /// 
        /// Initializes a new instance of the  class.
        /// 
        /// The nick.
        /// The full name.
        /// The encoding.
        public IrcClient(string nick, string fullName, Encoding encoding = null)
        {
            if (encoding == null)
                encoding = Encoding.UTF8;

            this.nick = nick;
            this.fullName = fullName;
            this.encoding = encoding;

            client = new MessageConnection();
            client.Disconnect += new EventHandler(client_Disconnect);
            client.SslValidate += new EventHandler(client_SslValidate);
            client.Message += new EventHandler(client_Message);
        }
        #endregion

        #region Client Events
        void client_Message(object sender, MessageEventArgs e)
        {
            throw new NotImplementedException("Implement handling commands.");
        }

        void client_SslValidate(object sender, SslValidateEventArgs e)
        {
            e.Accept = OnSslValidate(e.Sender, e.Certificate, e.Chain, e.SslPolicyErrors);
        }

        void client_Disconnect(object sender, EventArgs e)
        {
            OnDisconnect();
        }
        #endregion

        #region Properties
        /// 
        /// Gets a value indicating whether this  is connected.
        /// 
        /// 
        ///   true if connected; otherwise, false.
        /// 
        public bool Connected
        {
            get
            {
                return client != null && client.Connected;
            }
        }
        #endregion

        #region Events
        /// 
        /// Occurs when a SSL-certificate should be validated.
        /// 
        public event EventHandler SslValidate;

        /// 
        /// Occurs when the connection is disconnected from the other end.
        /// 
        public event EventHandler Disconnect;
        #endregion

        #region Public Methods
        /// 
        /// Connects the specified hostname.
        /// 
        /// The hostname.
        /// The port.
        /// if set to true connects using ssl.
        /// A task representing the async operation.
        public Task ConnectAsync(string hostname, int port, bool secureConnection)
        {
            return client.ConnectAsync(hostname, port, secureConnection).ContinueWith(task =>
            {
                throw new NotImplementedException("Implement sending of commands.");
                // PASS *
                // NICK 
                // USER dotRant 8 * :
            });
        }
        /// 
        /// Connects the specified hostname.
        /// 
        /// The hostname.
        /// The port.
        /// if set to true connects using ssl.
        /// A task representing the async operation.
        public void Connect(string hostname, int port, bool secureConnection)
        {
            ConnectAsync(hostname, port, secureConnection).Wait();
        }
        #endregion

        #region EventHelpers
        /// 
        /// Called when a ssl-certificate should be validated.
        /// 
        /// The sender.
        /// The certificate.
        /// The chain.
        /// The SSL policy errors.
        /// Whether or not to accept the sertificate.
        protected virtual bool OnSslValidate(object sender, X509Certificate certificate, X509Chain chain, SslPolicyErrors sslPolicyErrors)
        {
            SslValidateEventArgs args = new SslValidateEventArgs(sender, certificate, chain, sslPolicyErrors);
            if (SslValidate != null)
                SslValidate(this, args);
            return args.Accept;
        }

        /// 
        /// Called when the other end disconnects.
        /// 
        protected virtual void OnDisconnect()
        {
            if (Disconnect != null)
                Disconnect(this, new EventArgs());
        }
        #endregion
    }

As always, if there are any questions, please leave a comment below. The code for this post can be found here: https://github.com/Alxandr/dotRant/tree/part-4/src/dotRant.

Until then. Alxandr.

dotRant: Making an IRC library for .NET in C# – Part 3: A word about asynchronism (and some bug-fixes)

Alxandr — Tue, 18 Oct 2011 09:59:23 +0000

In my previous post we created a MessageConnection to be used with our IRC-library. The MessageConnection in it self might be used for other things than IRC though, but for but our goal is to implement it in our IRC-library. However, as I might have stated in my previous post, the code posted there was never tested. Thus, the likeliness of there being bugs is pretty high, and as one would suspect I found several of them. Some of the bugs were pretty trivial (like forgetting to append CRLF to the messages we send to the server), but others were more severe. Let’s start by fixing the first one, which was that we need to append CRLF to all messages sent from our application. To fix this is fairly simple, just update the Send-method to look like this:

        /// 
        /// Sends the specified message.
        /// 
        /// The message.
        public void Send(byte[] message)
        {
            message = RemoveCrLf(message);
            var buffer = new byte[message.Length + 2];
            message.CopyTo(buffer, 0);
            buffer[buffer.Length - 2] = 13; // CR
            buffer[buffer.Length - 1] = 10; // LF
            logger.Debug(">> {0}", Encoding.UTF8.GetString(message));
            lock (sendBuffer)
                sendBuffer.Write(buffer, 0, buffer.Length);
            TransferData(null);
        }

The next couple of bugs are a bit worse. They concern the DataReceived-method, and two of them is about copying arrays, and the last one is about what happens when the connection to the other end is lost. To tackle the problem with lost connections I’ve added a event called “Disconnect”, and a “OnDisconnect”-method (same as with the other events), and then I’ve added the following piece of code right after the EndReceive-call in DataReceived

            if (receivedDataLength == 0)
            {
                logger.Debug("Disconnected");
                client.Close();
                OnDisconnect();
                return;
            }

Next, in the same function you want to replace

buffer.CopyTo(data, bufferLength);

with

Array.Copy(buffer, 0, data, bufferLength, receivedDataLength);

and then you want to replace

byte[] message = new byte[i];
Array.Copy(data, msgStart, message, 0, i); // Copy data[msgStart:i] to message

with

byte[] message = new byte[i - msgStart];
Array.Copy(data, msgStart, message, 0, i - msgStart); // Copy data[msgStart:i] to message

After this is done we can move on to the next topic.

Asynchronism

As I might have stated earlier, I want dotRant to run async. There are several good reasons to this and I’ve already taken measures to make sure most of dotRant is async, but there is still one thing that can cause a freeze if it takes too long time. This can be bad, it will also make connecting to several servers at once take unnecessarily long time as we’d have to wait for each connection to finish before starting on the next. So, I’ve changed the Connect-methods to ConnectAsync-methods that returns a Task-instance, and then I’ve also created two new Connect-methods that runs synchronously, that use our async implementations and wait for their completion. The code is pretty simple and self-explanatory, so I’m just gone post it.

        /// 
        /// Connects the specified end point.
        /// 
        /// The end point.
        /// if set to true connects using ssl.
        public Task ConnectAsync(IPEndPoint endPoint, bool secureConnection)
        {
            if (Connected)
                throw new InvalidOperationException("Cannot connect when already connected");
            if (client == null)
                client = new TcpClient();

            logger.Debug("Connecting to {0}:{1}", endPoint.Address, endPoint.Port);

            var asyncResult = client.BeginConnect(endPoint.Address, endPoint.Port, null, null);
            return Task.Factory.FromAsync(asyncResult, result =>
            {
                client.EndConnect(result);
                if (!secureConnection)
                {
                    networkStream = client.GetStream();
                }
                else
                {
                    if (String.IsNullOrWhiteSpace(hostname))
                        throw new InvalidOperationException("Can't use ssl without specifying a host-name");

                    networkStream = new SslStream(client.GetStream(),
                        false,
                        new RemoteCertificateValidationCallback(ValidateServerCert),
                        null);
                    try { ((SslStream)networkStream).AuthenticateAsClient(hostname); }
                    catch (AuthenticationException ex)
                    {
                        logger.Warn("Certificate not accepted, exception: {0}", ex);
                        throw ex;
                    }
                }
                messagesBuffer = new MemoryStream();
                sendBuffer = new MemoryStream();
                networkStream.BeginRead(buffer, 0, buffer.Length, new AsyncCallback(DataReceived), null);
            });
        }
        /// 
        /// Connects the specified hostname.
        /// 
        /// The hostname.
        /// The port.
        /// if set to true connects using ssl.
        public Task ConnectAsync(string hostname, int port, bool secureConnection)
        {
            this.hostname = hostname;
            return ConnectAsync(new IPEndPoint(Dns.GetHostAddresses(hostname)[0], port), secureConnection);
        }
        /// 
        /// Connects the specified end point.
        /// 
        /// The end point.
        /// if set to true connects using ssl.
        public void Connect(IPEndPoint endPoint, bool secureConnection)
        {
            ConnectAsync(endPoint, secureConnection).Wait();
        }
        /// 
        /// Connects the specified hostname.
        /// 
        /// The hostname.
        /// The port.
        /// if set to true connects using ssl.
        public void Connect(string hostname, int port, bool secureConnection)
        {
            ConnectAsync(hostname, port, secureConnection).Wait();
        }

Should you find any mistakes, or have any questions, please contact me or leave a comment. The entire source-code can be found on link below:
https://github.com/Alxandr/dotRant/tree/part-3/src/dotRant

Until then. Alxandr.

dotRant: Making an IRC library for .NET in C# – Part 2: The message connection

Alxandr — Fri, 07 Oct 2011 06:57:59 +0000

Last time I showed you the basics of how IRC works. If you have yet to read that part, I recommend you read it. As I showed you, IRC works by sending commands back and forth, from the client and the server. The commands are separated by “CRLF” (windows newline), and consist of only text. This makes parsing of IRC pretty easy, so today we’ll start by creating what I call a message connection. But first, for those of you who have not worked with networking in .NET before, a quick summary.

Networking in .NET can be done in several ways. We can use plain old sockets, or we can use one of the wrappers that are provided to us for simplicity (like the “TcpClient”-class). Personally I like to work with the socket-class, however, as I want our library to be able to connect to servers using SSL and TLS, I’ve found that you need to have a Stream, and those are simply provided to us by the “TcpClient”-class, so for simplicity we are using that one, or rather, the “NetworkStream” we get from it. Streams support 2 things in basic, sending and receiving of binary data. That means that we need to interpret the data as text ourselves. Also, networking can be done asynchronously, and synchronously. We need to implement our library asynchronously, because we want it to be event-driven, so that when we receive a message we tell the application that a message has been received, rather than the application waiting for messages for us. Anyway, enough about that for now, we can get back to that later. One more thing before we start. I’m using NLog to implement logging in our library. Just thought I’d let you know. Now, let’s start with some code already xD.

MessageConnection

Let’s first begin with an empty class named MessageConnection, containing a logger and a TcpClient.

using System.Net.Sockets;
using NLog;

namespace dotRant
{
    /// 
    /// A class used to create a message TCP-connection
    /// with a server.
    /// 
    public class MessageConnection
    {
        private static Logger logger = LogManager.GetCurrentClassLogger();

        private TcpClient client;
    }
}

Currently this class does absolute nothing, but it’s a start at least xD. What we first need is the ability to connect to a server, however, we don’t want the user to be able to connect to a server if a connection is already existing, so let’s add a property to check if the connection is existing or not. Here’s the property

        /// 
        /// Gets a value indicating whether this  is connected.
        /// 
        /// 
        ///   true if connected; otherwise, false.
        /// 
        public bool Connected
        {
            get
            {
                return client != null && client.Connected;
            }
        }

Connecting

Now that we have that out of the way, we can start writing on a Connect-method. A Connect-method should take 2 parameters: The “EndPoint” we want to connect to, and whether or not to use a secure connection. However, constructing “EndPoint”-instances can be a pain, so it should also have an overload which takes 3 parameters; the hostname/ip-address to connect to, the port number, and whether or not to use a secure connection. Also, I’ve already mentioned supporting secure connections requires a stream, so we should add that to our class, because if we are to use a secure connection we use an “SslStream”, which is a wrapper for a normal Stream, so we need to address it when sending and receiving messages. So, go ahead and add a “Stream” to our class, and call it “networkStream”. Also, we need a string containing the hostname for when we are to authenticate using Ssl, so go ahead and add that too, then we can make our Connect-methods.

        /// 
        /// Connects the specified end point.
        /// 
        /// The end point.
        /// if set to true connects using ssl.
        public void Connect(IPEndPoint endPoint, bool secureConnection)
        {
            if (Connected)
                throw new InvalidOperationException("Cannot connect when already connected");
            if (client == null)
                client = new TcpClient();

            logger.Debug("Connecting to {0}:{1}", endPoint.Address, endPoint.Port);
            client.Connect(endPoint);
            if (!secureConnection)
            {
                networkStream = client.GetStream();
            }
            else
            {
                if (String.IsNullOrWhiteSpace(hostname))
                    throw new InvalidOperationException("Can't use ssl without specifying a host-name");

                networkStream = new SslStream(client.GetStream(),
                    false,
                    new RemoteCertificateValidationCallback(ValidateServerCert),
                    null);
                try { ((SslStream)networkStream).AuthenticateAsClient(hostname); }
                catch (AuthenticationException ex)
                {
                    throw new NotImplementedException("Not yet implemented.");
                }
            }
            throw new NotImplementedException("Begin reading data.");
        }
        /// 
        /// Connects the specified hostname.
        /// 
        /// The hostname.
        /// The port.
        /// if set to true connects using ssl.
        public void Connect(string hostname, int port, bool secureConnection)
        {
            Connect(new IPEndPoint(Dns.GetHostAddresses(hostname)[0], port), secureConnection);
            this.hostname = hostname;
        }

Now, there are a few thing to note here. First of all, line 24, we register a callback for validating the remote server-certificate. This is yet to be implemented in our class. Also, there are two places in our method where a NotImplementedException is fired. The first one is whenever there was an error in authenticating with the server (they had the wrong certificate for instance), and the second is when we are done connecting, cause then we want to start listening for data.

Receiving data

Let’s start by implementing listening for data, as that can be done pretty simply. What we need is a buffer for the data to be downloaded into, and then we need a new method. But lets start with creating a byte[] called buffer and add it to the class. Initialize it to be of BUFFER_SIZE size, and define a const int BUFFER_SIZE that is set to 4096. Then replace the NotImplementedException call at the bottom of the first Connect-method with this:

networkStream.BeginRead(buffer, 0, buffer.Length, new AsyncCallback(DataReceived), null);

That’s a start. Now, whenever our client has finished connecting it will start listening for data, and the data will be put into the buffer-array. Now we just need to implement our DataReceived-method and we are done with that part, but first, a small explanation on some networking is due. One of the “problems” with sending data over the network is that you never know how it’s going to arrive. You send a bunch of bytes, and TCP guarantees you (as long as there is a connection) that the data will arrive in the same order as it was sent, however, what it does not guarantee is that the data arrives as a blob the same size as it was sent. Let me explain this with a example rather. If I send 500 bytes of data to server B, then right after that I send 500 more bytes, there is nothing wrong with server B receiving that as one blob of 1000 bytes. That however is still easy to handle, the problem is when you send 500 bytes, and it arrives as 200, then 200, then 100. If all those 500 bytes was one command you need to sow it back together before you can parse it, and to do so, we need a second buffer. However, this can’t be a simple byte-array, because we have no idea of the size of commands that might arrive from the server. There are several possible methods to solve this. We could use a List of bytes, we could use a MemoryStream, or we could even use a StringBuilder. The problem with using a StringBuilder (or any type that want’s to store the buffer as a string rather than bytes) is that it is possible to retrieve a part of a message in such a way that one char get’s split in two. For instance, say we use UTF-8 and transfer the letter “å”. The letter “å” get’s encoded as the bytes [0xC3,0xA5]. It is possible that we received the first of the two bytes as one message, then the last one. If we only received the first one and try to parse that as UTF-8 to store it in a string, we’d get an error in our message, therefore it’s better to use bytes as the buffer. In dotRant I will implement this second buffer as a MemoryStream, and I will call it messagesBuffer. I will also initialize it just before I call BeginRead in the Connect-method.

A short description of how DataReceived needs to work before we start making it: DataReceived is called whenever there is new data available from the server. However, as discussed in the previous section, we can not know that what we receive is one command, it might be more, and it might be less. In the case that it’s more, it’s quite simple, we just split it up by “CRLF”, however, if there are less we need to store what we received, so that we can add that to the data we receive next time DataReceived is called. That too however might be more than one message, and so forth. I think the best way to show this is to show the code, but I just thought I’d explain my thoughts about how to write this function before actually showing it to you.

        private void DataReceived(IAsyncResult result)
        {
            int receivedDataLength = networkStream.EndRead(result);
            int bufferLength = (int)messagesBuffer.Length;
            int totalDataLength = bufferLength + receivedDataLength;
            byte[] data = new byte[totalDataLength];
            messagesBuffer.ToArray().CopyTo(data, 0);
            buffer.CopyTo(data, bufferLength);
            messagesBuffer.SetLength(0);
            // At this point data is all the received data, including what was in the buffer, and the buffer is emptied.

            int msgStart = 0;
            for (int i = 0; i < data.Length - 1; i++)
            {
                if (data[i] == 13 && data[i + 1] == 10) // byte 10 = LF and byte 13 = CR
                {
                    byte[] message = new byte[i];
                    Array.Copy(data, msgStart, message, 0, i); // Copy data[msgStart:i] to message
                    logger.Debug("<< {0}", Encoding.UTF8.GetString(message));
                    throw new NotImplementedException("Handle the message");
                    msgStart = i = i + 2;
                }
            }

            // What is left from msgStart til the end of data is only a partial message.
            // We want to save that for when the rest of the message arrives.
            messagesBuffer.Write(data, msgStart, data.Length);

            // Start listening again
            networkStream.BeginRead(buffer, 0, buffer.Length, new AsyncCallback(DataReceived), null);
        }

A note about the DataReceived function; on line 19 there is a new “NotImplementedException”. What we want to do here is tell whatever class created this MessageConnection that there is a new message. So, what we need is to create an event, then fire that event. But to get data sent trough an event we need first create a “EventArgs”-class. Let’s call this “MessageEventArgs” and have it look like this:

using System;

namespace dotRant
{
    /// 
    /// EventArgs-class used when a new Message is received in the  class.
    /// 
    public class MessageEventArgs : EventArgs
    {
        private byte[] message;
        /// 
        /// Initializes a new instance of the  class.
        /// 
        /// The message.
        public MessageEventArgs(byte[] message)
        {
            this.message = message;
        }

        /// 
        /// Gets the message.
        /// 
        public byte[] Message
        {
            get { return message; }
        }
    }
}

Then lets create an EventHandler event in the MessageConnection-class, and let’s call it “Message”, after that let’s make a virtual protected function named OnMessage that looks like this:

        /// 
        /// Called when a new message is received.
        /// 
        /// The message.
        protected virtual void OnMessage(byte[] message)
        {
            if (Message != null)
                Message(this, new MessageEventArgs(message));
        }

Now we’re getting close to something. Replace the NotImplementedExceptoin in DataReceived with a call to OnMessage, and our class is done with the aspect of receiving data.

Sending data

Sending data is much simpler than receiving, simply because we don’t need to parse it. However, we need to make sure that the data we send don’t contain “CRLF”, and append “CRLF” at the end of the data. Let’s start by creating a Send-method that takes a byte-array as it’s only parameter. It should check to see that we are connected, then it should send the data async. However, by sending the data async would mean that there is a chance that the Send-method will be called again before it’s finished sending, and we need to handle that scenario. What we should do is to implement a sendBuffer, the same way we implemented a messageBuffer. Also, in the same way DataReceived is called whenever there is new data available, we can have a function be called whenever it’s finished writing, so we just need that function to continue sending if there is anything in the buffer. First we should create a MemoryStream that is named sendBuffer the same way we did with messageBuffer, then we should initialize it at the same place we initialized the messageBuffer too.

        /// 
        /// Sends the specified message.
        /// 
        /// The message.
        public void Send(byte[] message)
        {
            message = RemoveCrLf(message);
            logger.Debug(">> {0}", Encoding.UTF8.GetString(message));
            lock (sendBuffer)
                sendBuffer.Write(message, 0, message.Length);
            TransferData(null);
        }
        private byte[] RemoveCrLf(byte[] data)
        {
            MemoryStream ms = new MemoryStream();
            for (int i = 0; i < data.Length; i++)
            {
                if (i < data.Length - 1 && data[i] == 13 && data[i + 1] == 10) // byte 10 = LF and byte 13 = CR
                    continue;

                ms.WriteByte(data[i]);
            }
            if (ms.Length != data.Length)
                return RemoveCrLf(ms.ToArray());
            return data;
        }

The “TransferData”-methodcall that’s been made here has yet to be written. It will do the actual sending of the data, however, it will also be called whenever sending is complete. An interesting fact to se here is the lock-statement I’ve wrapped sendBuffer.Write in. This is to make sure that there are no errors when running this “Send”-method from several threads at once. Now, let’s write the TransferData-method. However, for it to function properly we need to add another private member to our class. A bool named sending.

        private void TransferData(IAsyncResult result)
        {
            if (result != null)
            {
                networkStream.EndWrite(result);
                lock (sendBuffer)
                    sending = false;
            }
            MemoryStream ms = null;
            lock (sendBuffer)
            {
                if (sending)
                    return;

                if (sendBuffer.Length != 0)
                {
                    sending = true;
                    ms = new MemoryStream();
                    sendBuffer.CopyTo(ms);
                    sendBuffer.SetLength(0);
                }
            }
            if (ms != null)
                networkStream.BeginWrite(ms.ToArray(), 0, (int)ms.Length, new AsyncCallback(TransferData), null);
        }

Now our class is nearly complete. We have sending, and we have receiving of data. There is only one thing lacking.

Authentication using SSL

As shown earlier in this post, we need to handle authentication of our client when we want to use a secure connection. To do this we need to implement one function (“ValidateServerCert”), and we also have a NotImplementedException in the event that the authentication failed. Now, what I would like for our “MessageConnection”-class to do when we try to authenticate with the server is to call out to the handling class and let it decide what to do, and to do so we should implement an event. However, before we do so, let’s just implement a vanilla-implementation of the ValidateServerCert-function like this:

        private bool ValidateServerCert(
              object sender,
              X509Certificate certificate,
              X509Chain chain,
              SslPolicyErrors sslPolicyErrors)
        {
            return OnSslValidate(sender, certificate, chain, sslPolicyErrors);
        }

Before we go ahead and create our OnSslValidate-function, let’s create a new EventArgs-class like we did with the MessageEventArgs, this one should be called “SslValidateEventArgs”.

using System;
using System.Net.Security;
using System.Security.Cryptography.X509Certificates;

namespace dotRant
{
    /// 
    /// EventArgs-class used when authenticating using ssl in the  class.
    /// 
    public class SslValidateEventArgs : EventArgs
    {
        private object sender;
        private X509Certificate certificate;
        private X509Chain chain;
        private SslPolicyErrors sslPolicyErrors;
        private bool accept;

        /// 
        /// Initializes a new instance of the  class.
        /// 
        /// The sender.
        /// The certificate.
        /// The chain.
        /// The SSL policy errors.
        public SslValidateEventArgs(object sender, X509Certificate certificate, X509Chain chain, SslPolicyErrors sslPolicyErrors)
        {
            this.sender = sender;
            this.certificate = certificate;
            this.chain = chain;
            this.sslPolicyErrors = sslPolicyErrors;
            this.accept = false;
        }

        /// 
        /// Gets the sender.
        /// 
        public object Sender
        {
            get { return sender; }
        }

        /// 
        /// Gets the certificate.
        /// 
        public X509Certificate Certificate
        {
            get { return certificate; }
        }

        /// 
        /// Gets the chain.
        /// 
        public X509Chain Chain
        {
            get { return chain; }
        }

        /// 
        /// Gets the SSL policy errors.
        /// 
        public SslPolicyErrors SslPolicyErrors
        {
            get { return sslPolicyErrors; }
        }

        /// 
        /// Gets or sets a value indicating whether this certificate is accepted.
        /// 
        /// 
        ///   true if accepted; otherwise, false.
        /// 
        public bool Accept
        {
            get { return accept; }
            set { accept = value; }
        }
    }
}

Notice the “Accept”-value that wasn’t present in our OnSslValidate-method. This Accept-value is used to set wheaten or not to accept the certificate, and should be the return-value of OnSslValidate. Now we can implement OnSslValidate pretty easily, like this (note I’ve already added the event EventHandler SslValidate):

        /// 
        /// Called when a ssl-certificate should be validated.
        /// 
        /// The sender.
        /// The certificate.
        /// The chain.
        /// The SSL policy errors.
        /// 
        protected virtual bool OnSslValidate(object sender, X509Certificate certificate, X509Chain chain, SslPolicyErrors sslPolicyErrors)
        {
            SslValidateEventArgs args = new SslValidateEventArgs(sender, certificate, chain, sslPolicyErrors);
            if (SslValidate != null)
                SslValidate(this, args);
            return args.Accept;
        }

Now, what we should do is to edit the catch-block of the Connect-method to log the error, than rethrow it. And then we’re done. Should you find any mistakes, or have any questions, please contact me or leave a comment. The entire source-code can be found on link below:
https://github.com/Alxandr/dotRant/tree/part-2/src/dotRant

Until then. Alxandr.

dotRant: Making an IRC library for .NET in C# – Part 1: The IRC protocol

Alxandr — Thu, 06 Oct 2011 03:47:47 +0000

Hi, and welcome to my first blog-series ever. This blog series is about creating a IRC library in C#, that can (hopefully xD) be used by any .NET language. If you do not know what IRC is, it stands for “Internet Relay Chat” and is an old chatting-protocol. Not that many people use IRC anymore, and many people don’t see a reason why they should use it either. For me the point about IRC is that it takes a bit of a different approach on chatting than most modern chatting-application, and it’s made to chat with groups, not single persons. The point with IRC is that you enter a “room”, or a “group”, and then send messages to them, as opposed to applications like WLM which are made to send person to person messages. I know that most modern IM’s also has the capability to do group-chats, but you need to be invited to those. You can’t just join a group based on its name and talk to persons you have never talked to before, and that’s what I use IRC for.

Then the question comes to mind, why on earth would I want to write a library for IRCing in .NET? The answer is simple, to make a bot. Or several bots actually. And in some feature, I’d really like to create an IRC client in WPF, simply for the fun of doing it, but currently I’m focusing on the bot part. Another thing to know about this series is that I don’t know when it’s going to be finished, or how complete my library will be when I reach that point, because, to simply make a capable IRC bot, does not require it to understand all of the data coming from the IRC server. It can simply disregard what it doesn’t understand, and that works out just fine. The same can be said for all IRC clients. Most clients I’ve used, if they receive something they don’t understand, they simply display it to the user as-is, without any changes, and display it as a message received from the server itself. But anyways, we’ll see more about that when we get a little further.

The IRC protocol

The IRC protocol is a simple protocol which makes creating an IRC C# library a task that’s not very complicated looking at the network part. The protocol consists of sending messages, or commands as I’ll refer them as, back and forth from the client and the server. These messages should be within a certain size (I don’t know if there is actually a set limit for the command-size, but I’ve experienced servers rejecting commands that are too long), and consists of a prefix (only received messages as far as I know), a command-name, and a (possibly empty) sequence of parameters. The parameters are separated by one or more spaces, and the command is separated by “CRLF” (windows, and telnet newline). The prefix is generally who sent the command (which might vary depending on the command), and the command-name is ether a string of letters, or a number. The prefix and the command-name is also separated by a space. Empty commands are allowed (you can send one by sending “CRLFCRLF”), and they are simply ignored by the receiver. Parameters are separated by space, and can thus normally not contain spaces, however, as this would be pretty inconvenient (you would only be able to send messages with one word) the last parameter can contain spaces by prefixing it with a colon (‘:’). An example of this would be the command below, it shows the command to send a message to the channel “#test” containing the text “This is simply a test.”.

PRIVMSG #test :This is simply a test.

To connect to an IRC network you first need to identify yourself. This isn’t like login with username and password to enter, it’s simply telling the server who you are, and what you would like to be called. This is done with the “USER”, “PASS” and the “NICK” commands. “NICK” can also be used later to change your nick to something else. An example of what a connecting client would send to the server when it connects would be something like this:

PASS *
NICK 
USER guest 8 * :

What happens here is that the user tells the server that it would like to login with the nick , and that its full-name is . The 8 in the “USER”-command signifies that the user would like to be invisible, and the * in the USER-command is an unused parameter placed there for legacy-reasons.

Some of the important commands to know in IRC are the following:

PASS: Used when connecting to a server. In theory (and maybe in practice too) servers might have a password set, to disable users from connecting that don’t know the password, but normally you just pass “*” as the password
NICK: Used to set your nick. May result in the server sending an error complaining about the fact that the nick you picked is already in use by someone else.
USER: Used when connecting, mostly specifies full name.
PRIVMSG: Used to send messages to users or channels (groups).
JOIN: Used to join a channel.
PART: Used to leave a channel.
PONG: Used to answer the server’s ping-requests

All of these are commands that should be sent to the server from the client. One of the things that’s important to notice is the “PONG” command. From time to time the server will send you a “PING” command (if you are not active). This is to ensure that the client has not disconnected. If you do not reply to the “PING”, the server will assume that you have lost the connection, and disconnect from you. This means no more IRC until you reconnect, which is not a good thing as you probably will miss messages. “PING” is sent from the server with a single parameter, and you just have to send “PONG” back with the same parameter. Simple as that.

IRC in telnet

To try out the IRC protocol, the simplest thing to do is to test it out using telnet. If you are on Windows, you might need to turn on the telnet-client (“turn windows features on/off” from control panel). To connect to an IRC server you need to know it’s host-name or ip, and the port it’s listening on (usually 6667 for normal and 9999 for ssl). To connect, simply open a command-prompt (cmd in windows, terminal on mac, and if you are on linux and don’t know how to get a command prompt then shame on you) and type “telnet “. At first, after it’s connected, you will probably not see anything (except for an empty console). To start, you need to send the “PASS”, “NICK” and “USER” commands. After you have done this, wait a few seconds, and data should be popping down in your console. Simple as that. If you have any problems at all with getting this to work, please leave me a comment in the comment-section, and I’ll get back to you so we can figure out what is wrong).

What’s next?

Now, this was a long post about writing a library in C#, and without a single line of code. However, I hope I’ve given you a brief explanation of how IRC works, and that is required to know before we start building our library. In the next post we will start coding, and laying the foundation for the dotRant IRC library.

Until then. Alxandr.

MutableObject 1.2 – Reset the state of mutable-objects.

Alxandr — Wed, 05 Oct 2011 19:38:56 +0000

I just updated MutableObject with a new feature which I just thought I’d show. To make this short (I don’t have time for long posts right now) I’ll just post a unit-test that shows the new behavior perfectly.

public interface Interface1
{
	string Name { get; set; }
}

public class Class1 : Interface1
{
	public string Name { get; set; }
}

[TestFixture]
public class MutableObjectTests
{

	[Test]
	public void CanResetTest()
	{
		Interface1 obj = new Class1();

		obj.Name = "Per";

		Interface1 obj1 = Mutate.CreateMutableObject();
		Interface1 obj2 = Mutate.CreateMutableObject(obj);

		obj1.Name = "Knut";
		obj2.Name = "Knut";

		Assert.AreEqual(obj.Name, "Knut");

		Mutate.Reset(obj1);
		Mutate.Reset(obj2);

		Assert.AreEqual(obj.Name, "Per");
		Assert.IsFalse(Mutate.PropertiesIsSet(obj1, "Name"));
	}
	
}

I’ve also edited my nuget-build-rutine (for later releases) so that it includes the xml-documentation for the methods. Hope someone finds this useful .

Later.

MutableObject – Track state of simple CLR objects

Alxandr — Mon, 03 Oct 2011 23:07:29 +0000

I recently released my very first package to NuGet. Enter MutableObject, used to create and manage CLR-objects that you can track state of with a few simple calls. Ever came into a situation where you wanted to know what properties has changed since some point in your code? To do so, you needed to rewrite every setter in the entire class, and that’s simply painful to do when this is a task that could be solved automatically. MutableObject solves this, but let me just illustrate this problem first:

public interface IContact
{
    int Id { get; set; }
    string Name { get; set; }
    string Email { get; set; }
}

public class Contact : IContact
{
    public int Id { get; set; }
    public string Name { get; set; }
    public string Email { get; set; }
}
public class ContactRepo
{
	public IContact GetContact(int id)
	{
		// Lots of db-code to get the contact. Not LinqToSql or Entities,
		// plain SQL here.
		if(!result)
			return null;
		return new Contact
		{
			Name = name,
			Email = email,
			Id = id
		};
	}

	public void Update(IContact contact)
	{
		var dbContact = GetContact(contact.Id);
		var qb = new StringBuilder("UPDATE Contacts SET ");
		// Get all the changed properties and loop trough and add
		// the property to the update-query.
		qb.Append(" WHERE Id = ").Append(contact.Id);
	}
}

Now this is just a dummy-problem that I constructed to illustrate how MutableObject might be used, but I think this shows it pretty well. For instance, I’m using concatenation to construct a SQL-query (which you simply shouldn’t do in this day and age). Anyway, my point was to talk about MutableObject, so, in VisualStudio fire up the nuget package manager and run “Install-Package MutableObject”. Then, let’s change our GetContact-method a tiny bit to enable the use of MutableObject.

public IContact GetContact(int id)
{
    // Lots of db-code to get the contact. Not LinqToSql or Entities,
    // plain SQL here.
    if(!result)
        return null;
    var contact = new Contact
    {
        Name = name,
        Email = email,
        Id = id
    };
    return Mutate.CreateMutableObject(contact);
}

Now, what we did was to make sure that the GetContact-method returns a MutableObject and not just a simple Contact. The MutableObject returned implement all of IContact (as long as there are only properties), so the object returned from GetContact can be used just like normal. This is called creating a MutableObject with a base-object. The base-object is the contact we passed in as it’s only parameter. It’s also possible to create a MutableObject without a base-object, but if you do, and you try to read a property without setting it first, it will throw an exception. If a MutableObject is created with a base-object (i.e. it is “bound”), all changes done to the MutableObject will be reflected in the base-object, however, you should be careful about changing the base-object after the MutableObject is created, as that is something I have never tried to do, and I have no idea of what the result will be.

Once you have a MutableObject (which you can confirm by calling Mutate.IsMutable(object obj)) you can essentially do two things with it, you can use it like any normal .Net classes, and set/get properties as you like, and you can get a list over the properties that has changed since the MutableObject was created. You can also check if a property/properties is set with the Mutate.PropertiesIsSet(object obj, params string[] propertyNames), however, when using bound items this will always return true.

Now, let’s update our Update-method so that it actually builds the query.

public void Update(IContact contact)
{
	var dbContact = GetContact(contact.Id);
	var qb = new StringBuilder("UPDATE Contacts SET ");
	var props = Mutate.GetChangedProperties(contact);
	foreach(var prop in props)
		qb.Append(prop.Key).Append(" = \"").Append(prop.Value).Append("\", ");
	qb.Remove(qb.Length - 3, 3);
	qb.Append(" WHERE Id = ").Append(contact.Id);
}

And there you have it! Ofcause MutableObject could be inproved (and I plan to do so in the feature). One of the things I plan to implement is the ability to reset the MutableObject, or create a new MutableObject with another mutable-object as a snapshot without applying changes back to the original MutableObject, but that’s all for another time. Hope you can find some use for it . Leave me a comment if there is anything you want to ask or don’t understand.

Later.

An introduction to System.Reflection.Emit and OpCodes

Alxandr — Sat, 16 Oct 2010 21:17:20 +0000

A couple of days ago I wrote a tutorial describing how to create a proxy-class generator using System.Refleciton.Emit. After viewing the statistics of what people search for when they enter that tutorial it is clear that the problem seems to be getting dynamic functions created with System.Reflection.Emit to work with DateTime values. I had the same problem myself working with the proxy-class generator, and I thought I’d try to explain a bit. I’m no expert on this subject, but I think I’ve understood enough of it to make it useful, and I will try to tell you what I’ve found out about how the IL-code you generate should look like.

I’m also going to try to make this as practical as possible, so first let’s start by creating a console-application. And then we want to create a method that simply outputs something to the console, just to make sure that everything is working as we expected it to. But before we start writing any methods, I’ve come up with a simple extension-method that will simplify our code a little, add the following few lines to your project:

public static class MethodExtensions
{
	public static object InvokeStatic(this DynamicMethod method,
		params object[] args)
	{
		return method.Invoke(null, args);
	}
	public static T InvokeStatic(this DynamicMethod method,
		params object[] args)
	{
		return (T)method.InvokeStatic(args);
	}
}

This provides a cleaner way to call the methods we create later on. But let’s get started, the first thing we want to do is simply to make our method write something to the console, just to make sure that everything works the way we expect it to. Create a method “Method1″ that returns a DynamicMethod, and write the following in it:

static DynamicMethod Method1()
{
	DynamicMethod method1 = new DynamicMethod("Method1", typeof(void),
		new Type[] { });
	ILGenerator il = method1.GetILGenerator();
	il.EmitWriteLine("Method 1 here");
	il.Emit(OpCodes.Ret);

	return method1;
}

This creates a method that calls Console.WriteLine with the parameter “Method 1 here”. This is the simplest thing you can do with the DynamicMethod, but it’s still a start. The next thing we want to do is to provide the function with a parameter specifying what to write. This isn’t much hard either, the code can look like this:

static DynamicMethod Method2()
{
	DynamicMethod method1 = new DynamicMethod("Method2", typeof(void),
		new Type[] { typeof(string) });
	ILGenerator il = method1.GetILGenerator();
	il.EmitWriteLine("Method 2 begin");

	il.Emit(OpCodes.Ldarg_0);
	il.Emit(OpCodes.Call, typeof(Console).GetMethod("WriteLine",
		new Type[] { typeof(string) }));

	il.EmitWriteLine("Method 2 end");
	il.Emit(OpCodes.Ret);

	return method1;
}

Notice the call to Ldarg_0. This loads the first argument onto the stack. On point to notice though, is that if this was a member-function to some class, Ldarg_0 would load the “this”-object onto the stack. But since this is a “static” function (has no this), arg_0 is the first argument passed in to the function. If you have used python (the programming language) before, this is a lot like the methods in python expects the arguments to be. After the argument is loaded onto the stack, the correct overload of “WriteLine” on the console is called.

Ok, so that’s about it for writing out strings. Also, this was the basic of passing arguments to our function, for the next example, let’s try returning a string. This isn’t hard to do either, you only need to know how it works. To return a value it needs to be the only element on the stack when you call the “ret” statement, and if you function is a void-function this will cause your program to crash, so in void-functions the stack should be empty.

To return the string passed in, simply write this:

static DynamicMethod Method3()
{
	DynamicMethod method1 = new DynamicMethod("Method3", typeof(string),
		new Type[] { });
	ILGenerator il = method1.GetILGenerator();

	il.Emit(OpCodes.Ldstr, "This is a string from method 3");
	il.Emit(OpCodes.Ret);

	return method1;
}

Thats about it for working with complex objects, and types that are passed by reference for now. As most of you probably know there exists two different types of variables in C# and in .NET in general. You have the value-types like int, float, double, etc., and you have the reference-types like string, Window, and all normal classes in general. What people probably don’t know is that a struct is also a value-type (this is the biggest difference between classes and structs if I’m not mistaken). However, a trait of the C# language (and other .NET languages too) is that everything can be passed around as an object (which is reference-type). This includes integers, floats, strings, and everything else. If you create an object-variable in C#, no matter what you try putting in it, you won’t get an error. However, to use the data-piece it either needs to be casted, or looked upon with reflection.

What most people don’t know is that when you take a value-type value and put it in an object-reference, an action is performed on the value-type variable before it is put in the object-reference. This action is called boxing. When you assign an integer or a DateTime or any other value-type value to a object-reference, boxing is done for you automatically, and you don’t really see that it’s done, and when you cast it back, it’s unboxed automatically too. However, when working with System.Reflection.Emit and OpCodes, the boxing and unboxing needs to be taken care of by the programmer (you). But before we start with that, let’s look at a simple example that takes in a DateTime, and returns it, this is fairly strait-forward since there is no object-references involved at all.

static DynamicMethod Method4()
{
	DynamicMethod method1 = new DynamicMethod("Method4", typeof(DateTime),
		new Type[] { typeof(DateTime) });
	ILGenerator il = method1.GetILGenerator();

	il.Emit(OpCodes.Ldarg_0);
	il.Emit(OpCodes.Ret);

	return method1;
}

This works as you would expect it to. You pass the function a DateTime-object and it returns it just like we wanted it to. However, what if we were to make this function into an object-function? If we replace the typeof(DateTime) (the last one) in the creation of the method, and call the method the same way you will get an error, and your code will not work. That is because when you pass the DateTime to the object-function it is automatically boxed for you, and before you can return it as a DateTime-object you need to unbox it. If you try this code however, it should work as the last example:

static DynamicMethod Method5()
{
	DynamicMethod method1 = new DynamicMethod("Method4", typeof(DateTime),
		new Type[] { typeof(object) });
	ILGenerator il = method1.GetILGenerator();

	il.Emit(OpCodes.Ldarg_0);
	il.Emit(OpCodes.Unbox_Any, typeof(DateTime));
	il.Emit(OpCodes.Ret);

	return method1;
}

And if we were to switch the parameters, so that the function accepted a DateTime and returned an object, we’dd just have to switch the Unbox_any with Box, and it would still work. As for a last example, I will provide you with a function that takes in a DateTime and prints it. The overload of the Console.WriteLine I’ll use is the WriteLine(Object) overload. The code is as following:

static DynamicMethod Method6()
{
	DynamicMethod method1 = new DynamicMethod("Method5", typeof(void),
		new Type[] { typeof(DateTime) });
	ILGenerator il = method1.GetILGenerator();

	il.EmitWriteLine("In function 6: ");
	il.Emit(OpCodes.Ldarg_0);
	il.Emit(OpCodes.Box, typeof(DateTime));
	il.Emit(OpCodes.Call, typeof(Console).GetMethod("WriteLine",
		new Type[] { typeof(object) }));

	il.Emit(OpCodes.Ret);

	return method1;
}

If you have any questions please leave them in the comment-section.

Creating a proxyclass-generator using System.Reflection.Emit

Alxandr — Fri, 15 Oct 2010 02:24:27 +0000

I started the other day writing something which I thought might be pretty awesome. A proxyclass-generator. I had no idea at the time how this could be done, but I new it could, because wcf uses something of the sorts. The idea was as following: I want to be able to create a interface as following:

public interface InterfaceA
{
    void DoSomething();
    int GetInt();
    int Multiply(int int1, int int2);
    string TrimString(string str);
}

Then I want to pass that interface to an object or a constructor and get out an object implementing that interface, and also I want to define what happens whenever any and all of the functions are called. The syntax I ended up with is something like this:

ProxyGenerator pg = new ProxyGenerator(IProxyHandler handler);

In this case the IProxyHandler is a simple interface with one function, and that function gets called whenever any function is called on the proxied object. The IProxyHandler-interface looks as following:

public interface IProxyHandler
{
    object OnMethod(MethodInfo method, object[] args);
}

Ok, now we basically have everything we need to start building the ProxyGenerator. But there is a few more decisions to be made. Firstly, I decided that the work of the ProxyGenerator should be done in the constructor, so that the construction of the class is the only thing that is time-consuming. In the constructor we will make our assembly, module and proxy-class. Also, all proxy-classes will be in the same assembly, and in the same module. So the module and the assembly we create our proxy-classes in will be static and thereby “cached” in the ProxyClass, last but not least we don’t want to create the same proxy-class twice, so it should be cached too.

The barebone ProxyGenerator-class (without the acutall proxy-generating) looks as following:

public class ProxyGenerator
{
	private static volatile bool built;
	private static AssemblyBuilder assemblyBuilder;
	private static ModuleBuilder moduleBuilder;
	private static readonly object buildLock = new object();
	private static Dictionary typeCache = new Dictionary();

	private TypeBuilder typeBuilder;

	private T obj;

	public ProxyGenerator(IProxyHandler handler)
	{
		/* do the magic */
	}

	public T Object
	{
		get { return obj; }
	}
}

The built-boolean indicates wheater or not the assembly and module is created, the buildLock is a lock-object to make shure that the assembly and module dosn’t get created twice in different threads, and the typeCache is (as the name suggests) the cache used to store the proxy-classes we’ve created. All of this should be pretty straight forward. The T obj; is where we want to store an instance of the acutal proxy-class. The class will automatically get instantiated.

The first thing to do is to create the assembly and the module, and for this we use the AssemblyBuilder and the ModuleBuilder located inside the ProxyClass’ static variables. Also, we must remember to check if the assembly and module is already created, and we must make it thread-safe. To do so, insert the following code into the constructor:

lock (buildLock)
{
	if (!built)
	{
		assemblyBuilder = AppDomain.CurrentDomain.DefineDynamicAssembly(
			new AssemblyName("NirQ.Proxies"),
			AssemblyBuilderAccess.Run);

		string assemblyName = assemblyBuilder.GetName().Name;

		moduleBuilder = assemblyBuilder.DefineDynamicModule(assemblyName);
	}
	built = true;
}

I recon you all know the meaning of the lock-keyword, and how it is used, and the rest of the code is pretty straight forward. First we define an assembly named “NirQ.Proxies” (or you might rename it to whatever you like), then create the module. All of the classes proxy-classes created hereafter will be added to the module here created. However, creating an assembly is probably not something you want to do if the class itself isn’t able to be created, so before the code above, add the following three lines:

Type t = typeof(T);
if (!t.IsInterface)
	throw new ArgumentException("T needs to be an interface");

After the generation of the assembly and the module we need to make sure that a proxy-class for this interface has not been created earlier. This is done simply by checking for the typename in the typeCache like so:

if (typeCache.Keys.Contains(typeName))
{
	result = typeCache[typeName];
}
else
{
	// Create the class
}

And now’s about the time when the fun part starts. Creating a “on-the-fly”-class like this is not actually anything that’s hard to do at all, but the hard part is creating the methods that can be called on the class. But before I start talking about that there are some few more lines of code that should be added to the constructor, namely the creation of an empty class that implements the interface given. This should be added inside the else-part of the if-else above.

typeBuilder = moduleBuilder.DefineType(
	String.Format("{0}_NirQ_proxy", t.Name),
	TypeAttributes.Class | TypeAttributes.Public,
	typeof(Object),
	new Type[] { t });

This is a hard to crack nut. The DefineType method on the moduleBuilder has several overloads, but the one I’m using accepts the following arguments: The name of the new class, typeattributes (like this is a public class), the base of the class (for inheritance), and an array of interfaces whom the class inherits. In other word, our class will be named the same as the interface, with “_NirQ_proxy” appended, it’s a public class that inherits from object (same as a default class), and inherits the interface t (t = typeof(T), T is the type-argument given to the class, ie the interface to implement).

Ok, so now we got an empty class. If we try to compile the class as is, we would get an error because the class does not implement all the methods of the interface (unless the interface is empty, or only contains methods already in Object (like “string ToString()”). But before we start implementing the interface itself, lets start with the constructor and the variables we’ll be using. One thing we want to do in a constructor (I don’t know if this is required, but I think it’s good practice) is to call the base constructor. To do so we first need to get a MethodInfo, or rather a ConstructorInfo that represents the constructor we want to call. To get them is simple, just use the following two lines of code:

Type objType = Type.GetType("System.Object");
ConstructorInfo objCtor = objType.GetConstructor(new Type[] { });

The parameter used for GetConstructor is an empty Type-array to specify that we want the default constructor with no parameters. Next thing we want to do is to define a class-wide private variable. This variable will hold the IProxyHandler passed in as a parameter the the constructor we’re currently writing. The proxy-class needs to know of the IProxyHandler so that it can route method-calls to the handler in action. The code to create this field is realy simple, it’s a single line like this:

FieldBuilder proxyFieldBuilder = typeBuilder.DefineField("handler", typeof(IProxyHandler), FieldAttributes.Private);

Ok, and now onto the actual creation of the constructor. To create a constructor we call the DefineConstructor on our TypeBuilder. It needs to know if the constructor should be public/internal/private etc, it’s calling-conventions and the parameters it takes. In this case the function is a instance-method, and has the calling-convention “CallingConventions.HasThis”. The actual functionality of the constructor (like calling the base constructor and saving the parameter as a variable) comes later. The code goes as following:

ConstructorBuilder constructorBuilder = typeBuilder.DefineConstructor(
	MethodAttributes.Public,
	CallingConventions.HasThis, new Type[] { typeof(IProxyHandler) });

Next up is creating of the actual constructor. What we want the constructor to do is to call the base constructor, then to save the parameter passed to the function onto the private variable. The method used to achieve this is trough the System.Reflection.Emit namespace, and the methode used is ILGenerator.Emit(). The IL-code is a sort of a stack-machine, so if you don’t know what that is you can read along and try to understand, but I would suggest doing some research on the subject. Also, one thing to notice is that we often load in the argument index 0. This is not the first argument to the function (that is argument index 1), but rather the “this” object. Also, whenever you call a function values are popped and pushed onto the stack, so it’s important to keep you head straight. One of the problems I had in early stages was calling return while there was something left on the stack on a void-function. This is the code for the constructor, I will try my best to explain it in detail after the code itself:

ILGenerator cIl = constructorBuilder.GetILGenerator();

cIl.Emit(OpCodes.Ldarg_0); // Load this to stack
cIl.Emit(OpCodes.Call, objCtor); // Call base (object) constructor

cIl.Emit(OpCodes.Ldarg_0); // Load this to stack
cIl.Emit(OpCodes.Ldarg_1); // Load the IProxyHandler to stack
cIl.Emit(OpCodes.Stfld, proxyFieldBuilder); // Set proxy to the actual proxy

cIl.Emit(OpCodes.Ret);

What this code does is: First it loads the “this”-object onto the stack. Than it calls the base constructor (Object.Object()), when the constructor is called it pops the “this”-object of the stack, and since it’s a constructor and not a function that returns anything, it doesn’t push anything back onto the stack. Now we want to store the argument passed in (arg_1) in the IProxyHandler field (proxyFieldBuilder). This is more tricky, as the operations seems to be in reverse, but what happens is the following. First we load this onto the stack, then we load the IProxyHandler onto the stack. Then we call the Stfld-command, which takes what lies at the top of the stack, and stores it in the field provided in parameter 2 of the function, on the object that lies on top of the stack after the previous one’s been popped. So in other word: read top of stack and pop and save at field in top of stack, then pop again. Now the stack is empty and we can exit the function (by calling Ret).

Next up is creation of the member-methods in the interface, but before we do that we need to have the function we want to call on the IProxyHandler available. This is done simply by the following code:

MethodInfo callRetMethod = typeof(IProxyHandler).GetMethod(
	"OnMethod",
	BindingFlags.Instance | BindingFlags.Public | BindingFlags.NonPublic,
	null,
	new Type[] { typeof(MethodInfo), typeof(object[]) },
	null);

Ok, lets start looping trough all the methods in the interface; the following is the rest of the code for the else-clause we’re currently in:

foreach (MethodInfo mi in t.GetMethods())
{
	// Implement the method
}
result = typeBuilder.CreateType();

typeCache.Add(typeName, result);

Now, all that’s left is to actually implements the methods and instantiate an object of the class we created. As you probably might have guessed this is more stack-machine, but I’ll try taking it one step at a time. The first thing we want to do is to define the method. Also, we want to know the number of parameters the function is supposed to take, and then we start the ILGenerator. This is pretty straight forward, it’s done as follows:

MethodBuilder mb = typeBuilder.DefineMethod(mi.Name,
	MethodAttributes.Public | MethodAttributes.HideBySig |
	MethodAttributes.NewSlot | MethodAttributes.Virtual, mi.ReturnType,
	mi.GetParameters().Select(pi => pi.ParameterType).ToArray());

int privateParameterCount = mi.GetParameters().Length;

ILGenerator il = mb.GetILGenerator();

The first thing we want to do in the function is to declare an object-array to hold the parameters, and a MethodInfo-variable to hold the current method being called. Remember that the IProxyHandler.OnMethod expected this.

To create the array we first declare it. Then we create a new object-array at the top of the stack and then we store that array at the newly declared variable (first declaration, then initialization). Also, to create an array a size must be specified. That size must lay on the top of the stack when we call the Newarr-call. To load a constant integer onto the stack we use Ldc_I4 (must be int32). The code is as shown below:

LocalBuilder argArray = il.DeclareLocal(typeof(object[]));
il.Emit(OpCodes.Ldc_I4, privateParameterCount);
il.Emit(OpCodes.Newarr, typeof(object));
il.Emit(OpCodes.Stloc, argArray);

The MethodInfo-variable is even more tricky. To get the MethodInfo we first load what is called a token (which is a unique reference of sort to either a method, class, or the likes if I understood the documentation correctly) of the MethodInfo we have at build-time (remember, the IL-code we generate isn’t compiled yet). Then we need to call MethodBase.GetMethodFromHandle(RuntimeMethodHandle handle) on the token. The code itself isn’t that hard, but the tricky part was to figure out about MethodBase.GetMethodFromHandle, and how to call it. The code can be seen below.

LocalBuilder methodInfo = il.DeclareLocal(typeof(MethodInfo));
il.Emit(OpCodes.Ldtoken, mi);
il.Emit(OpCodes.Call, typeof(MethodBase).GetMethod(
	"GetMethodFromHandle", new Type[] { typeof(RuntimeMethodHandle) }));
il.Emit(OpCodes.Stloc, methodInfo);

Ok, now that we’ve created the array and the MethodInfo-object we need to populate the array. This isn’t too hard a task, but what we need to remember is that there exist different types of types in .NET, and while in code putting the number 3 into an object-object might seem fine, in IL that doesn’t work. Every so-called value-type (including int, float, and all structs like DateTime) needs to be “boxed” before they can be referenced like an object. This isn’t hard at all, but you need to know that you need to do that in order for it to work properly, or else the application will crash if you try to give it a valuetype like an int. Also, one thing to notice is that when we loop trough the parameters the function take, the loop is on the build-side of the code. This means that once the function is called (after it is created), there is no loop at all. It has no ifs, no elses, no loops, no nothing at all except doing the bare minimum of what’s required. In other word, if I were to write this function in C# it would look something like this:

void DoSomething(int arg1, string arg2, DateTime arg3)
{
	object[] argArray;
	argArray = new object[3];
	
	MethodInfo methodInfo;
	methodInfo = MethodBase.GetMethod(*someHandle*);
	
	argArray[0] = box(arg1, int);
	argArray[1] = arg2;
	argArray[2] = box(arg3, DateTime);
}

Note here though that box is a fictive function, and that the boxing normally is taken care of by the c#->IL compiler for you. But as you can see though, no loops. To put an element into an array we use the Stelem_ref-call. The Stelem_ref-call expects the first item on the stack to be the item to put into the array. The next item should be an integer specifying it’s position, and the last item should be the array itself. The whole loop to populate the array looks like this:

for (int i = 0; i < privateParameterCount; i++)
{
	ParameterInfo info = mi.GetParameters()[i];

	il.Emit(OpCodes.Ldloc, argArray);
	il.Emit(OpCodes.Ldc_I4, i);
	il.Emit(OpCodes.Ldarg_S, i + 1);
	if (info.ParameterType.IsPrimitive || info.ParameterType.IsValueType)
		il.Emit(OpCodes.Box, info.ParameterType);
	il.Emit(OpCodes.Stelem_Ref);
}

The next part is also pretty simple. The first thing you do is load the “this”-object (arg_0) onto the stack. Then you use Ldfld to get the proxyFieldBuilder-field (which pops the “this”-object and replaces it with the IProxyHandler). Then we load the methodInfo local variable (which is the first parameter of “OnMethod”), and we load the argArray (which is the second parameter of “OnMethod”). And at last we call “OnMethod” with the loaded parameters. This will pop argArray, methodInfo and the proxyFieldBuilder, and push the result of the function onto the stack. The only thing that’s left on the stack now is in other words the result of the OnMethod-call. However, the OnMethod-call always returns an object, so if the function we’re writing want’s an int, we have to unbox it first. This is done with Unbox_all. Also, if the function we’re writing is a void-function we don’t want to return anything, regardless of what the OnMethod returned, so we just pop the value of the stack before calling Ret. This leaves the remaining code in the foreach-loop like this:

il.Emit(OpCodes.Ldarg_0);
il.Emit(OpCodes.Ldfld, proxyFieldBuilder);
il.Emit(OpCodes.Ldloc, methodInfo);
il.Emit(OpCodes.Ldloc, argArray);
il.Emit(OpCodes.Call, callRetMethod);
if (mi.ReturnType.IsValueType && mi.ReturnType != typeof(void))
	il.Emit(OpCodes.Unbox_Any, mi.ReturnType);

if (mi.ReturnType == typeof(void))
	il.Emit(OpCodes.Pop);

il.Emit(OpCodes.Ret);

Now there’s only one thing left, and that is to instantiate the class we just made. This is to be put outside the if-else loop we started nearly at the beginning of this constructor (the test to check if the type was cached). We use the Activator to create an instance, then simply cast it to T and assign it to obj. The code is below:

object o = Activator.CreateInstance(result, new object[] { handler });
obj = (T)o;

And there you have it. A fully working proxy-generator which you may use in any way that you want to. For example I’ve used this to create a small framework for server-client communication that is seamless. I hope you learned something, and please leave a comment if you have any questions or if you just like the article.

Starting to blog again

Alxandr — Mon, 11 Oct 2010 23:42:36 +0000

I’ve never been any good at this blog-thing, but I’ve always found the idea appealing. I myself reads several blogposts a day whenever there’s a coding-problem that I don’t know how to solve, but sometimes the results not that easy to find, and you end up reading documentations and stuff like that (which might not always be easy to understand without good viewcases). And it happens that one has to find the solution to some trivial matters all by one self.

Whenever I find myself in one of those kind of situations I always think when I’m done “I should blog about this”. Though in the end I never do. But I will try to get better at this, so that one day people searching for a solution to a problem which I’ve solved might find it with just a little googling. So that I might give back to the rich blog-community that already thought me how to program.

That being said, look forward to seeing my next blog-post as it will probably be around soon. That is, if anyone actually read this though . Later.