December 7, 2007

TCP Socket War (C# and TcpListener)

I have just spent the better part of two days fighting a socket bug that turned out to be a simple fix. Isn't it funny how the time consuming ones always turn out to be something simple? I have been using .Net's TcpListener to create a server/client applications. The advantage of using the TcpListener is that it does all of the standard socket setup for you. You also still have access to the socket and the network stream that is used in case you still need the extra power that comes with manipulating them yourself. The way I set this thing up is by having both the client and server loop forever to listen for incoming data. This is done using BeginRead(...) on the network stream.

myTcpClient.GetStream().BeginRead(data, 0, size, new AsyncCallback(dataReceived), state);

This will have the app listen on another thread so that I can do my other business. When data is received, the callback method that was passed in will be called. What is cool about this is that you can still send on the socket while you are listening in the background! Gotta love it.

I had been developing my server and my client and all seemed to be going well. Then I decided to put my client on another computer so that i could do more testing. The computer of choice happened to be connected via a wireless connection. When I started up my client application, my client started to break! Further investigation yielded that my data was being corrupt on the way to my client (or so I thought). It made no sense that my data was getting corrupt because TCP is made to assure that all of your data arrives, that it is the right data, and that it arrives in order. I would later discover that if I sent enough data in a single send, that my client would also break on a wired connection... even if both the client and server were on the localhost. I tried everything I could think of to fix this problem, but nothing seemed to be working out. I even tried breaking my data up into smaller packets with no luck.

Well after wasting the better part of two days on this, I was doing yet another debug session to try to figure things out. Again, I realized that all of my data was not arriving at the client. For some reason, this time a light bulb went off. You see, I had been operating on the assumption that since I was using an asynchronous read (BeginRead) instead of a synchronous read (Read) that the thread would not return until either an error had occurred or until 'size' number of bytes were read. I don't feel so bad because I had others tell me that this is how it works too. Don't expect the MS documentation to spell this out for you either. The truth of the matter is that because I was working on my local network with technically small amounts of data, I was receiving all of it before BeginRead was returning... that is until I switched to a slower wireless connection.

The solution is simple. All you have to do is check the number of bytes received and see if you got the number of bytes you were expecting. If you didn't then you will have to call BeginRead again and pass the number of remaining expected bytes in as your size. You get the number of bytes read when you call EndReceive.

int readBytes = myTcpClient.GetStream().EndRead(callbackAsyncResult);

This is basically the same technique as used when you implement synchronous reads. I was also using an abnormal technique to get my data, which probably helped delay my figuring this out. The way my app works is that I take a serializable object and serialize it with BinaryFormatter. I then take the length of the byte array produced and convert it to bytes with BitConverter. I then append the length bytes to the front of my object's bytes. This new byte array is what I actually send over my TCP socket stream. When the data arrives on the other side, I immediately pop off 4 bytes (the size of an integer) so that I get my length. I then create a buffer that is the size of my length and read in length bytes on my next call to BeginRead. Typically people have a fixed buffer size and read continuously until they get their expected length. I guess thats what I get for doing things my own way ;-)

Boy do I feel better!

December 4, 2007

Creating a plug-in interface using C# and .Net Reflection

I finally had the excuse recently to look into creating my very own plug-in interface. A plug-in essentially allows a piece of software to load dll files (more pieces of code) that it knows virtually nothing about before runtime. I was very impressed at how simple this is using .Net and its reflection implementation. When I began to research this topic, I found all kinds of articles that show you how to achieve this in a particular way. I would later find out that the common way to go about it is very inefficient. The reason for this is that .Net's reflection implementation has some very inefficient routines. Reflection is sluggish by nature; the parts of reflection that are not so sluggish were given special optimization attention because they are commonly used by .Net. I won't go into much more detail on this because I am by no means an expert on the matter, but I will point you to some very good literature.

This article will explain some of the insides of reflection and explain which parts are inefficient and why:

http://msdn.microsoft.com/msdnmag/issues/05/07/Reflection/

This article is something of a quick-reference guide to which reflection methods you should watch out for:

http://msdn.microsoft.com/msdnmag/issues/05/07/Reflection/default.aspx?loc=&side=true#a

This article will show you the ''common" way of implementing a plug-in interface (this is the inefficient way, see below for the better solution):

http://www.codeproject.com/KB/cs/ayassemblyattributes.aspx?df=100&forumid=33248&exp=0&select=798913


Now for the good stuff! So like I said before, your host application needs to know virtually nothing about the plug-in it will be using. However, in order to achieve a simplified and clean implementation for both you and your plug-in implementers, you need to set up a standard that both parties will go by. To do this, you will need to create an interface. An interface will allow you as the host application to use a single implementation for every plug-in of a certain type. It will also give your plug-in implementers a code path into your application. Here is an example interface:

public interface Iplugin
{
//You can have a method such as Initialize
//that will pass the plugin an object
//that will give the plugin access to information
//and functionality on the host.
//This could be done by creating an interface
//that your host will implement
//which will contain methods/properties that
//your plug-ins are meant to access
//and then passing the host object into
//the initialize function.
//We do this in an Initialize method because an
//interface cannot define constructors.
void Initialize(someObject info);

//I like to have my plug-in give some sort of
//description that I can use for
//logging or to show to a user of my host application
//to help define what this
//plug-in will do
string GetDescriptor();

//all you need to do is define the methods that
//you will expect all plug-in
//implementations to implement
void DoMethod();
...
}


You will want to create a project by itself with just interfaces (and similar) so that you can give the dll to your implementers without having to give them any of your host implementation code. Your implementers will need to use this interface on their objects that provide plug-in functionality.

public class HelloWorldPlugin : Iplugin
{
someObject hostInfo;

public void Initialize(someObject info)
{
hostInfo = info;
}

public string GetDescriptor()
{
return "Host Displays Hello World";
}

public void DoMethod()
{
//use the access you have to the host via the hostInfo object
//to make something on the host happen
...
}
}


So now we have our interface for our plug-ins and we have a test plug-in that implements the interface. Now we need to figure out how to get that code from the dll into the running host application. This is done using reflection. You will somehow need to let your software know where your plug-in or plug-ins are at. This can be done by asking the user to enter a location, passing in the location in a config file, having a default plug-in location, etc. Once we have the location of the plug-in, we will use reflection to load the dll and read in the information about it. Another name for your dll is an Assembly. The reflection APIs are in System.Reflection.

Most articles you find on plug-ins will have you load the assembly and get back a list of all the types inside the assembly. They would then have you loop through each type and check if it implements your interface. If it does, you would then continue to create an instance of that type and start using the plug-in. This is where the inefficiencies come in. You can review the articles at the links above to see an example codeproject article showing you this inefficient method as well as an article from MSDN explaining why you should not do it that way.

To keep from having to get all of the types and loop through them, we are going to have our assembly give us a list of types inside of it that implement our interface. This is done using attributes. Using the attribute technique, you will require your implementers to add an attribute to their AssemblyInfo.cs file within their project's properties folder. With this attribute, your implementers can tell you which types in their assembly are implementing your Iplugin interface. By doing this we are trusting that the user will pass us the correct information. This means we should probably verify that the types they pass really do implement your interface before we actually start using it.

Since we will be using the attribute technique to make a more efficient plug-in interface, we will need to define our own attribute. It is actually very simple to do. In the same file that you create your Iplugin interface in, add this class.


[AttributeUsage(AttributeTargets.Assembly, AllowMultiple=true)]
public class PluginAttribute : System.Attribute
{
public readonly Type ImplementingType;

public PluginAttribute (Type implementingType)
{
ImplementingType = implementingType;
}
}


Now your implementers will need to add this line to their AssemblyInfo.cs file.

[assembly: PluginAttribute (typeof(HelloWorldPlugin))]


Your implementer will include one of those declarations per plug-in that they provide, replacing HelloWorldPlugin with whatever the types name is. Now when you load the plugin from your host application, the assembly will automatically contain these attributes without having to ask for a list of types that you will loop through (the inefficient part). Now lets look at the code that will actually load the plugin into the host application so that we can use it.


Assembly asm = Assembly.LoadFile(dllPath);

PluginAttribute [] typeAttribs = (PluginAttribute []) asm.GetCustomAttributes(typeof(PluginAttribute ), false);

foreach (PluginAttribute attr in typeAttribs)
{
Iplugin methodInstance = (Iplugin)Activator.CreateInstance(attr.ImplementingType);

//methodInstance is an object of your plugin type!
//now just do whatever you want with your plugin.
//perhaps store it somewhere so you can use it from now on.

methodInstance.Initialize(something);
methodInstance.DoMethod();
}


Dont forget, you might want to make sure the type that you got from your attribute actually implements your interface before you try to cast it as that type. Something bad will happen if your implementer passed you a type that does not actually implement your interface. The best thing to do would probably be to wrap your code with try{}catch{} just in case. I like to wrap everything with try/catch and then wrap my foreach loop with try/catch as well. This way if just one type was wrong, you can still use the others, and you will still be okay if there was a problem loading the assembly.

Have fun plugging in!

December 1, 2007

Form.Show() From Another THread - C#.Net

Today I ran into a mojor headache. I have a main form that instantiates a secondary form from its constructor. I also register to a receive data event that I have based on a socket. Because the socket uses threading, when my event delegate is called, it is being called from the context of another thread. It is inside the execution of the delegate that I ran into trouble. When I receive data from the socket, I want to open the secondary form and do something with it. Immediately I know that I am going to have to use Invoke on the secondary form in order to safely modify it from the other thread. My original attempt looked like this (I will use an inline delegate here to simplify this listing):

void dataReceived()
{
If(secondaryForm.InvokeRequired)
{
MethodInvoker myDelegate =
delegate
{
secondaryForm.Show();

//do other work on secondaryForm
};

secondaryForm.Invoke(myDelegate);
}
else
{
socondaryForm.Show();
//do other work on secondaryForm
}
}


If I run this code and call myDelegate manually (not from the other thread's event), everything would work fine. The form would show up and do exactly what I wanted. If I run this code and call Show on the secondaryForm manually, close it, then allow the event to call myDelegate, everything would work fine. The problem comes in whenever I run my code and allow the event to call myDelegate before ever showing the secondaryForm.

Whenever execution would get to "secondaryForm.Show()", my form would show up but would be frozen and messed up looking as if it were stuck an infinate loop or something. There would also be no errors thrown. After rearranging my code and retrying different approaches for a while, a light went off. Now I do not claim to understand all of the inner-workings of a windows window and message loop, but I have seen enough details to lead me to the correct solution. With that in mind, the following explaination may be based on some incorrect assumptions. Feel free to correct me if you know better :-)

Since I was calling Invoke from my secondaryForm, the delegate was being called from the context of the secondaryForm. Because of this, all of the modifications that I made to the form thereafter were done safely. Because the problem showed up only when I had not manually opened the form at least once before the event, I knew that it must have something to do with the secondaryForm not being inserted into the message loop properly when it was being called for the first time; or so it appears. The solution:

void dataReceived()
{
If(mainForm.InvokeRequired)
{
MethodInvoker myDelegate =
delegate
{
secondaryForm.Show();

//do other work on secondaryForm
};

mainForm.Invoke(myDelegate);
}
else
{
socondaryForm.Show();
//do other work on secondaryForm
}
}


All that I had to change was to call the Invoke method of the mainForm instead of the secondaryForm, and therefore the InvokeRequired method of the mainForm as well. This is where things get fuzzy for me. For some reason, I had to call the Show method of the secondaryForm from the context of the mainForm in order for the secondaryForm to be entered into the message loop properly. Perhaps this is because mainForm is the primary form (started from Application.Run) that is running on the GUI thread. I am not too sure. For all I know, this may just be a bug in .Net and have nothing to do with message loops and invoke contexts. I hope that someone will at least be able to benefit from this solution :-D If you can shed any light on what exactly is happening here, I welcome your comments.

November 29, 2007

Hello World

This blog will be my attempt to keep track of random coding techniques that I run across, or anything else code related that I find useful. If all goes well, I will begin adding posts soon.