1
2
3
4
5
6
7
8
9
10

public static void SendEmail(string to, string from, string subject, 
                             string message, string host, int port)
{
    SmtpClient c = new SmtpClient(host, port);
 
    MailMessage m = new MailMessage(from, to, subject, message);
    m.IsBodyHtml = true;
 
    c.Send(m);
}

Simple, eh? But it would fail. If I telnet’ed into their server and typed the SMTP commands to send an email, I would get a 550 5.0.0 Command Rejected” error message at the point where I try to send a “RCPT TO:” SMTP command. What’s the deal?!

Well, apparently the server did have a restriction that I had so far not known about. It had been configured with a GREET_PAUSE value for all emails. Typically that setting should only be set for incoming emails from external servers, and not for internal emails like this. But it was set for all emails.

GREET_PAUSE means that once an SMTP connection is made, the client who is connecting must WAIT until the server recognizes their connection before “blasting” SMTP commands through. Apparently SMTPClient just blasts the commands through. If a SINGLE character is received in that timespan, the server will reply as normal, but will reject any and all emails that are sent through.

I tried a couple fancy ways to make SMTPClient wait for a few seconds before sending data, but could not find an easy way. Apparently it does not support this capability out of the box (such that I could find.) So I resolved to just writing the email code myself. It’s not hard to do.

I added a greet_delay_ms integer to my parameters on my function:

1
2

public static void SendEmail(string to, string from, string subject, string message, 
                    string host, int port, int greet_delay_ms)

And replaced the simple SMTPClient code with this more complex code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

public static void SendEmail(string to, string from, string subject, string message, 
                       string host, int port, int greet_delay_ms)
{
    TcpClient c = new TcpClient(host, port);
    StreamWriter sw = new StreamWriter(c.GetStream());
    StreamReader sr = new StreamReader(c.GetStream());
    string data = "";
 
    // Wait the specified amount of time before sending an email
    // could probably also just do a sr.ReadLine() and let it block
    System.Threading.Thread.Sleep(greet_delay_ms);
 
    sw.WriteLine("helo " + from.Substring(from.IndexOf("@") + 1));
    sw.Flush();
    data = sr.ReadLine();
 
    sw.WriteLine("MAIL FROM:" + from);
    sw.Flush();
    data = sr.ReadLine();
 
    sw.WriteLine("RCPT TO:" + to);
    sw.Flush();
    data = sr.ReadLine();
 
    sw.WriteLine("DATA");
    sw.Flush();
    data = sr.ReadLine();
 
    sw.WriteLine("Subject: " + subject);
    sw.Flush();
    sw.WriteLine(message);
    sw.Flush();
    sw.WriteLine(".");
    sw.Flush();
    data = sr.ReadLine();
 
    c.Client.Close();
    c.Close();
}

Once I passed in 8000 or so as the time to wait, the emails poured through just fine. 8 seconds is a while to wait, but apparently that’s what this server requires.

In my table, I have a field “PayType” which is a char(1) and has valid values “S” and “H”. These mean “Salary” and “Hourly”, respectively.

I am showing this in a ListView in my screen I’m developing. So, when editing the record, I naturally wanted a dropdown box where you can choose “Hourly” or “Salary”. Note this will only work if you know what values you want in your dropdown box. If the selections are dynamic, then you will probably have to have a databound event and build the box manually.

I wanted it to default to the selected type for the record I’m editing when I click on edit, but could not find anything in the intellisence that looked correct for my Bind() call.

1
2
3
4
5
6
7

<asp:DropDownList 
      ID="ddPayType" 
      runat="server" 
      SelectedValue=<%# Bind("PayType") %>  >;
          <asp:ListItem Text="Salary" Value = "S" />
          <asp:ListItem Text="Hourly" Value = "H" />
</asp:DropDownList>

The answer was to Bind on the “SelectedValue” parameter. I was thrown off because SelectedValue does not seem to pull up in Visual Studio 2008 as an option on the list when writing code in the markup editor. But it correctly updates the value when the Update command is executed.

The Connection Class: Beginning Network Code

We are going to get into the fun part of the network code in this part of the series. This post will teach you how to use TcpClient to send and receive data over the network. TcpClient is a class in Microsoft Dot Net which instantiates a TCP connection and can send and receive data in the form of byte arrays.

Step 1: Create our connection class. Right-click on our Chat class library and add a new class. Call that class “Connection”. This class will use our Packet class to send and receive data.

Step 2: Include the correct using statements. We need to include certain dot net classes to make our coding job easier. Add these using statements to the top of Connection.cs.

1
2
3

using System;
using System.Net.Sockets;
using System.Net;

The TcpClient class we are going to use is included by using these statements. This will make our coding easier since we don’t have to fully qualify each time we use the TcpClient class.

Step 3: Instantiate our TcpClient object. Inside of your Connection class, add the following line of code which will create our TcpClient class. By creating one here, it will be instantiated with our Connection object and always be available.

1
2
3

    public class Connection
    {
        TcpClient c = new TcpClient();

We now have a client object named “c” to work with in our network code.

Step 4: Constructors. Let’s create a couple of constructors for our connection class. One constructor should take a TcpClient object as a parameter, so that it can accept one that’s already created. Another constructor should just take a server to connect to and the port to connect to, and open the connection.

1
2
3
4
5
6
7
8
9

        public Connection(TcpClient client)
        {
            c = client;
        }
 
        public Connection(string server, int port)
        {
            c.Connect(server, port);
        }

As you can see from the second constructor, opening a TCP connection to a given server with a given port is very easy to do. The call to Connect is a “blocking” operation, which as you should remember from Part 1 of this series means it will wait until the connection has been created successfully before continuing with any further code.

If the connection fails for any reason, an exception will be thrown. Any client code written using the Connection class should be able to handle that exception. As a matter of fact, every function in this class could possibly throw an exception, so your client code should always wrap network calls in a try/catch statement.

Users Table

The Linq seemed easy:

1
2
3
4
5
6
7
8
9
10

public static string GetNameOfUser(int userID)
        {
            DatabaseDataContext dc = new DatabaseDataContext();
 
            var user = from u in dc.Users
                       where u.UserID == userID
                       select u.FirstName + " " + u.LastName;
 
            return (user.Count() == 0) ? "Unknown User" : user.First();
        }

However my results were not correct. Bob was left out because he did not have a last name value (it’s NULL in the database.) You will get results like this if you run that for each user (one at a time, but I put them in a table here.)

Results

In SQL it is very common to use the COALESCE() function to handle problems with null values. But how can I do that in Linq? I didn’t want to write extra code to check for nulls and concatenate the values myself.

The answer is simple: ??. Yes, that’s right. Two question marks is the “coalesce” operator in Linq. It’s a good idea to wrap what you are testing in coalesce inside parenthesis as well.

What follows is my new function.

1
2
3
4
5
6
7
8
9
10

public static string GetNameOfUser(int userID)
        {
            DatabaseDataContext dc = new DatabaseDataContext();
 
            var user = from u in dc.Users
                       where u.UserID == userID
                       select (u.FirstName ?? "") + " " + (u.LastName ?? "");
 
            return (user.Count() == 0) ? "Unknown User" : user.First();
        }

As you can see, I’ve added ?? “” after both FirstName and LastName. This translates to:

coalesce(FirstName, ”)
coalesce(LastName, ”)

Which means that if FirstName is null you will get ”, which adds correctly in SQL to another string. Same goes for LastName.

Here are my new results:

Results

Table Referrers

Table ReferrerInfo

So I wanted to join these together using a Linq-To-SQL query. The first thought that occured to me was to use a join:

1
2
3

var referrers = from r in Referrers
               join ri in ReferrerInfo on r.ServerConnectionID equals ri.ServerConnectionID ..... ??????
               select r;

So, apparently in C# you cannot do multiple columns in your join. I have to join on both ServerConnectionID and ReferrerID.

This page: http://www.onedotnetway.com/linq-to-sql-join-on-multiple-conditions/ explains one method to do so, but unfortunately that Linq query only works in VB.

So, I ended up writing a Linq-To-SQL that just uses the old style of joining, by using the where clause!

1
2
3
4
5

var referrers = from r in Referrers
                from ri in Referrer_Info
                where r.ServerConnectionID == ri.ServerConnectionID &&
                   r.ReferrerID == ri.ReferrerID
                select r;

This successfully executes my multi-column join.

Here’s an example table:

There are lots of ways to achieve the desired result, but the simplest is to just use a simple SELECT statement combined with the ROW_NUMBER() function with a couple parameters as to how to number the rows!

ROW_NUMBER() provides you with the number of a row in a given recordset, where you provide details on how to number the records. For example, if I just had to number the records above based solely upon the date of birth (ignoring families) then I would use this query:

1
2
3
4
5
6
7
8
9
10
11

SELECT
     [PersonID]
    ,[FamilyID]
    ,[FirstName]
    ,[LastName]
    ,[DateOfBirth]
    ,ROW_NUMBER() over (ORDER BY DateOfBirth) AS Number
FROM
	People
ORDER BY 
	PersonID

This just tells the ROW_NUMBER() function to order its numbering ascending by DateOfBirth. Notice that I apply an order myself later on in the query, which is different than the row_number() order. I would get these results:

The number field that is assigned to each record is in the order of DateOfBirth.

Ordering my numbering by DateOfBirth is just half of the picture. I also need to “group” the records by the FamilyID. This is where a clause in T-SQL that you might not be very familiar with comes into play: “PARTITION BY”. The PARTITION BY clause allows us to group the results within the call to ROW_NUMBER() without grouping them ourselves via a GROUP BY. It just tells the ROW_NUMBER what groupings to use when it does its counting.

Here is our final SQL statement, which achieves the business logic we wanted to implement.

1
2
3
4
5
6
7
8
9
10
11
12
13

SELECT 
       [PersonID]
      ,[FamilyID]
      ,[FirstName]
      ,[LastName]
      ,[DateOfBirth]
      ,ROW_NUMBER() over(PARTITION BY FamilyID, 
                         CONVERT(NVARCHAR(25), DateOfBirth, 111) 
                         ORDER BY DateOfBirth ASC) TwinCode
 
  FROM [People]
ORDER BY
	PersonID

In the ROW_NUMBER function above, I am doing several things. I’m grouping on FamilyID, and also grouping on a converted DateOfBirth. I convert the DateOfBirth to an nvarchar using the 111 conversion code, because that gets results like ‘2009/10/11′ and ‘2009/10/12′ which can easily be grouped by to achieve distinct dates.

Grouping on the Family, DateOfBirth, and then sorting by DateOfBirth ascending achieves the desired result for the ROW_NUMBER. Here are the results of the query:

As you can see, the two people who qualify as twins above (Karly and Kacy) are enumerated correctly, with Karly receiving a 1 and Kacy receiving a 2. All the records that are not twins properly receive a 1.

This can be done with Computed (or Calculated) Columns. These columns are table-level expressions that can operate on the other fields in a given record.

Let’s create a table which uses computed columns. I am going to create a table called Programmers which allows me to store a programmer’s first name, last name, middle initial, and date of birth. The table will include two computed columns: one which combines the elements of the name into a FullName field, and a second column which tells me the programmer’s age. This will all be achieved directly in the table, without the use of a view.

First, let’s create the table. Here is the query to create all of the fields except the computed ones.

1
2
3
4
5
6
7

CREATE TABLE Programmers
(
	ProgrammerID INT IDENTITY(1,1) NOT NULL,
	FirstName NVARCHAR(30),
	LastName NVARCHAR(30),
	MiddleInit NCHAR(1),
	DateOfBirth DATETIME,

Now, let’s create our first computed column. The syntax is simple. Just begin with the name of the column, and then in parenthesis define the expression which will calculate the value of the column.

Let’s begin with the FullName calculation. Just add the LastName, a comma, FirstName, and MiddleInit, and then trim white space off the right to handle a missing initial.

1
2
3

        FullName AS (rtrim(coalesce(LastName, '') + ', ' +
            coalesce(FirstName, '') + ' ' + 
            coalesce(MiddleInit, ''))),

There we have it, our FullName calculation. Each field is encapsulated in coalesce to handle NULL values properly.

The last calculation will be the age. The age is simply the difference in years of the current date from the birth date.

1
2

	Age AS (datediff(year, DateOfBirth, getdate()))
)

We also add a following parenthesis to close out our “CREATE TABLE” statement.

Now lets insert some test data. I added a few records with some NULLs for good testing measure. All standard stuff here. Notice we are not inserting the FullName or Age values.

1
2
3
4
5
6

INSERT INTO Programmers(FirstName, LastName, MiddleInit, DateOfBirth)
     VALUES ('David', 'Andrews', 'C', '1984-09-20')
INSERT INTO Programmers(FirstName, LastName, MiddleInit, DateOfBirth) 
     VALUES ('Billy', 'Jenkins', NULL, '1990-01-20')
INSERT INTO Programmers(FirstName, LastName, MiddleInit, DateOfBirth) 
     VALUES ('Robert', 'Anderson', 'K', NULL)

Now lets test out our fields, using nothing more than a SELECT.

1

SELECT * FROM Programmers

We will get the following results:

I emphasized the calculated fields above. Our query did not calculate them, they were considered to be just a part of the table since they are calculated fields.

One thing to keep in mind about calculated fields is that they are difficult to modify. You have to DROP the field and then ADD it back with the same name. This can change the order of fields in your query if you use SELECT *. It can also affect any triggers you may have which rely on the fields being in a certain order.

Also keep in mind any overhead that calculated fields may produce. It’s a good idea to use them for absolutely basic, atomic information, such as what I presented above. Complex calculations could become taxing to your queries.

Let’s use these tables as an example.

AnimalTypes table

Animals table

Here we have a table called AnimalTypes which contains 4 types of animals, and a table called Animals which lists out animals and what type they are.

Let’s say we want to write a program which will display all the animals in our animals table, as well as the Name of the Type of the animal, not the ID of the type. If an animal has an unknown type, we want to display “UNKNOWN.” Here is the bad process that we want to avoid.

SELECT * FROM AnimalTypes
SELECT * FROM Animals

The bad program will then loop through all the animals and print out the Name field in the AnimalTypes results which corresponds to the given type ID. If one does not exist in the AnimalTypes results, the code could then print “UNKNOWN.”

It also might occur to you that you can write a query like this one, which would also be incorrect.

SELECT
      *
FROM
      Animals, AnimalTypes
WHERE
      Animals.AnimalTypeID = AnimalTypes.AnimalTypeID

This is the basis of an inner join. It can be written as an inner join query, but I wrote it in the manner above as an example. This query will return results, however you will only get animals who have a corresponding correct AnimalType. Our program wants to display all animals, regardless of whether or not they have a valid type selected. Using the tables from above, you would get these results:

If you notice, the animal Tails is missing from the list. This is because Tails’ AnimalTypeID of 5 did not have a corresponding AnimalTypeID in the AnimalTypes table. In a query such as this, both values have to exist in both tables. This is not the case in our data, even though we want all animals to display.

What we need to use in this case is a left join or a left outer join. The left join will take each record from the left-hand side of the join, and tie it to records on the right-hand side. If the tie does not exist in the right-hand table, then the left-hand fields will still exist in the results, with NULL values for the right-hand.

Here is the query using a left join.

1
2
3
4
5
6

SELECT 
     * 
FROM 
     Animals
     LEFT JOIN AnimalTypes
          ON Animals.AnimalTypeID = AnimalTypes.AnimalTypeID

What you get here is every record from Animals, joined to the corresponding AnimalType record. In the case of Tails, we won’t get any AnimalType information.

A very common use of this join is in financial transactions, where you might be missing the category of the transaction but still want the amount included.

We have above a table of animals. How can we determine the count of each type of animal? The simplest (and most inefficient) is to run a count() query for each type of animal. This would mean we have 3 queries to run, as there are 3 types of animals.

1
2
3
4
5
6
7
8
9

declare @numdogs int
declare @numcats int
declare @numferrets int
 
SELECT @numdogs = COUNT(*) FROM animals WHERE type = 'Dog'
SELECT @numcats = COUNT(*) FROM animals WHERE type = 'Cat'
SELECT @numferrets = COUNT(*) FROM animals WHERE type = 'Ferret'
 
SELECT @numdogs AS NumDogs, @numcats AS NumCats, @numferrets AS NumFerrets

We will get results from that query like this.

As you can imagine, this is terribly inefficient. A good answer in this case is to use a “conditional” sum in the SQL query. So rather than running COUNT(*) we will be running SUM(…). We will combine the SUM() call with a CASE statement, so that it counts correctly. This is the trick I hope to teach you. You can place CASE … END statements inside of aggregate functions.

Throw away all of our temporary variables, the 4 select statements involved, and let’s replace them with this single select.

1
2
3
4
5
6

SELECT 
	SUM(CASE WHEN type='Dog' then 1 else 0 end) AS NumDogs,
	SUM(CASE WHEN type='Cat' then 1 else 0 end) AS NumCats,
	SUM(CASE WHEN type='Ferret' then 1 else 0 end) AS NumFerrets
FROM 
	animals

We get these results:

Which is exactly what we got previously, but using a much more efficient method. The trick was to insert a CASE … END statement inside the SUM. The case will return a 1 when the type is the type we are looking for, and a 0 otherwise. The sum will then execute to add up all of those 0s and 1s. A 0 will not add anything, so we will effectively end up counting the values which match the type we are looking for.

This is the second installment of a multi-post tutorial on writing network software using the dot net framework and the C# programming language. In this installment we will be going over the ChatPacket class which implements the Packet abstract class.

The ChatPacket Class

If you recall, our Packet class had three important elements.

1. Type Code: This is an integer value which identifies the type of packet. It is transmitted across the connection for every packet, so that the receiving end knows how to interpret the packet it is receiving.
2. Converts to Byte Array: Every packet which inherits from our base packet class should be able to convert itself into a byte array.
3. Parses a Byte Array: The packet classes which inherit from the base class should implement a parse function which will take a byte array and read it into the proper packet structure.

These capabilities should be implemented by any class which inherits from Packet, so that the library stays consistent.

Let’s begin by creating a new class. Right-click on your Chat class library and add a new class called ChatPacket.cs. This file will be our main class for sending chat data back and forth.

Step 1: Inherit from Packet base class. Every packet class we create should inherit from the base Packet class. This is because the server and client code we will be using will use the base class in all of its operations.

1

public class ChatPacket : Packet

Step 2: Create the chat data property. Chat data is going to be just a string in our chat packet class. Let’s add a new property to our ChatPacket class.

1

public string ChatData { get; set; }

Chatdata is going to basically be the text of each chat packet that gets sent around. When you type in text to send out to the server (and the server sends it to the other clients) then this is the data that gets sent out.

Step 3: Constructor should set the Type of Packet. The next thing that must be done is that each packet must identify its type. This is so that the end point which receives every packet needs to know how to decode it into the correct class. In our constructor for each packet, we are going to tell the packet which type it is.

1
2
3
4

        public ChatPacket() 
        {
            _packetTypeCode = 1;
        }

Keep in mind that the type code should be unique to this type of packet. If we created another packet type in this application, its typecode should be set to 2 for each instance. ChatPacket is going to be packet type 1.

We are only going to send around ChatPackets, but it would be a good idea in a more complex program to use constants to make sure your packet types are consistent integer values.

Step 4: Implement ToByteArray() method. This is the method that will be called by our server to convert a packet into a stream of bytes. The network code will then send the bytes of the network, and the code at the other end will reconstruct the bytes into a packet.

1
2
3
4

        public override byte[] ToByteArray()
        {
            return Encoding.ASCII.GetBytes(ChatData);
        }

The above code uses the built-in ASCII encoding capabilities of dot net to convert our string of packet data into an array of bytes which can be transmitted.

Step 5: Implement the Parse operation which reconstructs packets. The Parse function takes as input a series of bytes and should return the reconstructed packet object.

1
2
3
4
5
6
7
8
9
10

        public static new ChatPacket Parse(byte[] packetData)
        {
            ChatPacket p = new ChatPacket();
 
            if(packetData.Length != 0) {
                p.ChatData = Encoding.ASCII.GetString(packetData);
            }
 
            return p;
        }

As you can see, the above function is fairly simple. It just does the opposite of the ToByteArray function, in that it uses the built-in ASCII Encoding classes to construct a string from bytes rather than deconstruct a string into bytes.

It returns a new packet object.

Completing the ChatPacket Class

So what we have done here is to create a class which will our packet class. ChatPacket is a very simple packet class, because the only data that is sent in the packet is the text of the chat message. It is a good idea to keep your packets very simple, so they can be easily and quickly packaged and processed.

In the next portion of this tutorial series, we are going to move on to implement the Server class and program, which is where this all gets interesting!