In this article I will be showing you how to create a client for our chat application. This is part two of the series, so if you haven’t read part one yet please do so before continuing with this article as it explains the infrastructure of the whole application. You can read part one here: C# Chat Application Over Asynchronous UDP Sockets – Part 1, The Server.
The Client
For our client to connect to the server, which is listening for incoming connections, the server must obviously be running :). Apart from that, the client must know the IP address of the server and which port the server is listening on. We already know from part one of this article series that the server is listening on port 30,000. However we don’t know the server’s IP address so that will have to be input manually from the user interface of the client.
The client will make use of the exact same Packet class we used for the server. In fact this class could have been placed into a library and included into each project as a dll instead of replicating the code twice… but it makes no difference for the purpose of this example, plus I didn’t feel like creating a dll :).
[continue reading…]
In this two-part article series I am going to show you how to implement a simple client-server chat application using asynchronous UDP sockets. In this first article of the series I will be focusing on the server of our chat application. The client will be discussed in part two.
What is UDP?
UDP, or User Datagram Protocol, is a connectionless protocol that runs on top of IP networks. UDP does not have an inbuilt mechanism to make sure that all the data being sent is received and received in order – instead such logic must be implemented in the application using the protocol.
UDP is typically used for streaming data such as video or audio, it is also used in VoIP, online gaming, and for broadcasting data over a network.
Application Infrastructure
The infrastructure we are going to use for this chat application is a simple client-server infrastructure as can be seen below:
The server will be the central point which all clients connect to, and the communication between server and clients will be done using a custom data packet which will contain the data being sent over UDP.
[continue reading…]
A few days back I discussed XML Serialization in these two articles: Basic XML Serialization in C#, and XML Serialization of Collections. In this article we are going to serialize the same Employee object we serialized in those articles, but this time we are going to use Binary serialization instead.
Binary Serialization vs. XML Serialization
You might think that binary serialization and XML serialization are the same thing, the only difference being the format of the data within the created file. Well if that is the case, you would be wrong.
Binary serialization is very different from XML serialization. XML serialization is not really an actual serialization technique – in fact one might argue that Microsoft did not name it that appropriately. XML serialization does not serialize the whole object – it only creates a stream of XML data which contains the public properties of the object while ignoring any private properties.
So how can you preserve the state of an object when you are ignoring its private properties? Well, you can’t. That’s where binary serialization comes in. With binary serialization all public and private properties are serialized, therefore retaining an exact copy of the object.
This statement can obviously be proven by opening the file of a binary serialized object with a hex editor and verifying that the private properties of the object are there, but since it is a binary file that could prove a bit problematic to read for the majority of us :).
There is a simpler way to prove this – you can monitor you class’s constructor when deserializing the file. When deserializing using XML deserialization, you will notice that the class constructor for your serialized object is called. Obviously this shows that XML serialization is not retaining a copy of the actual object, but it is re-building it by instantiating your class and then populating the public properties. With binary deserialization the serialized object’s constructor is never called, and that is because there is no need for it to be called because the whole object can be rebuilt through deserialization.
[continue reading…]
As a software developer, how many times have you needed to store your application’s settings in a file, be it an ini file, an xml file, or maybe even a plain text file? It is a common requirement for many developers, and with C# it is really simple to do.
The Microsoft.NET Framework 2.0 introduced a new item called the Settings File. This file is added to your project by default and can be found under the Properties folder within Visual Studio’s Solution Explorer. The default name for this file is Settings.settings and it contains an easy to use interface for adding your application settings at design time.
Settings File Properties
A settings file contains the following four properties:
- Name – The Name property is the name that is used to access the value of the setting through your code at runtime.
- Type – The Type is the .NET Framework type of the setting like for example
bool, decimal, int, and string. It even supports more complex types such as System.Drawing.Color, or System.Guid.
- Scope – This property specifies how a setting can be accessed at runtime. It can be one of two values – either User or Application. The main difference between these two is that Application settings are read-only at runtime, while user settings are not. User settings should be used to load/save user preferences such as for example colour settings or window positions. Application settings should be used to store settings required for your application to run such as connection strings for example.
- Value – The value property is the actual value that will be returned when accessing the setting at runtime.
[continue reading…]
In this third and final article of my File Comparison in C# series we will be creating a method which compares file hashes. I suggest you read File Comparison in C# – Part 1, and File Comparison in C# – Part 2 before continuing with this article, if you haven’t already done so.
What is a File Hash?
First of all a hash function is a mathematical function which converts a large sized amount of data into a much smaller datum. This datum is a representation of the actual large data, so it is ideal to use for data comparisons or database lookups for example.
So, a file hash would be the hash representation of a file. When you look at it, a hash is just a long numerical or alpha-numerical value, such as for example these two:
b7404b4dd5e4d1b67869226dcbc2da09
29-B4-1C-B3-54-F3-14-19-16-EE-0D-6A-F5-73-56-9F-DA-3F-D5-47
File Comparison using Hashes
To create our file comparison method we are going to use the .NET HashAlgorithm class. To use this class we need to add the System.Security.Cryptography namespace to our project.
[continue reading…]
