July 16, 2008

A Quick Note On Ports and Sockets

At this point, most people are familiar with the use of an IP address. Basically it is a unique number used on a network to identify a network computer. When we talk about computers communicating with each other, an IP address alone is useless. A single computer may have many programs running that want to communicate over the network. This means that a single address point (the IP address) is not enough to define what program a remote computer would like to communicate with. This is where port numbers come in. A program can bind itself to one or many open ports (meaning they are not currently in use by another program). Once bound to a port, a remote computer can communicate with a program by addressing the computer's address (IP) along with the program's address on that computer (Port).

A common misconception is that a socket represents a bound port on a computer (the IP:Port pair). In reality, this is only half of what a socket represents. In fact, a socket represents two IP:Port pairs: one for the host, and one for the client. This means that multiple remote computers can connect to a program via the same port while each connection is represented by a different socket. Each socket is unique because they each have a different remote IP:Port pair even though they all have the same host IP:Port pair. To take this a little further, one remote computer can have multiple connections to a port on a host. This is possible because each remote connection will be bound to different ports on the remote machine, again giving us unique IP:Port pairs for each socket connection.

The way this generally works behind this scenes goes something like this. The host computer will open a socket which it will bind to some port to listen for incoming connections. When a remote computer connects, the listening socket will create a new socket and bind it to the host and connecting remote IP:Port pairs. The original listening socket will then continue listening on its bound port for more incoming connections. Sockets are typically implemented in this way because only a single connection can be represented by a socket at a time. The original socket could have handled the communications of the incoming connection itself, but there would then be no socket open to listen for other incoming connections.

July 2, 2008

Visual Studio Project Settings

When I first started using the settings feature that was built into Visual Studio, I thought that they were pretty straight forward. It turns out that I had virtually no idea what was really going on. This is probably has mostly to do with MSDN's lack of documentation, as usual. Now I will attempt to lay out how this monster really works.

First goto the properties page of a project and goto the settings tab. From here you can set up either Application or User settings. It turns out that the differences are pretty self explanitory. A user setting will actually end up in a user.config file burried in the Documents And Settings folder for each user. This means that each user will be able to have a different set of settings for these. Application settings are actually read from the myapp.exe.config file in the application path (usually in Program Files).

To access these settings from code, all you need to do is:

string mySetting = Properties.Settings.Default.MySetting;

If you are accessing a user setting, the program will first look in the user.config file burried in the user's Documents And Settings, then in the myApp.exe.config file, and finally in the hardcoded default values. For an application setting, the same order is used starting at the myApp.exe.config file.

To add to the excitement, it turns out that it is only possible to save user settings from your application. If you are writing to a user setting to the user.config file in the user's Documents And Settings, all you have to do is:

Properties.Settings.Default.MySetting = mySetting;
Properties.Settings.Default.Save();

If you want to save a user setting or an application setting to the myApp.config file in the application's path, there is no built in way. You will have to resort to loading the file into an XML DOM API and edit the file manually.

The main point to recognize here is that even if you uninstall an application, the user settings will stick around in the Application Data for a user, and magically reappear next time the application is installed. These files must be removed if you want to reset your user settings.