July 16, 2008
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
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;
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.