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.

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!

Basics of Networking

The full methodologies of network programming are a beyond the scope of this article, so I will just give a very brief and elementary overview of how network programming works. We will be writing our chat server and client using the TcpClient and TcpServer classes which are built into System.Net in the dot net framework. These classes themselves are built on top of System.Net.Sockets, which wraps the socket structure provided by the operating system.

A “socket” is the basic connector in network communication. A socket can send and receive data, and a socket can listen for incoming connections. Think of an electrical wall socket in your home. It is sitting there, waiting for a connection. We call waiting for a connection “listening.” When you plug in a vacuum cleaner, the socket comes alive and provides electricity (the metaphor for network data) to the device. Plugging in the device is called “connecting” to the socket. When you unplug the vacuum cleaner, the flow is interrupted and the vacuum cleaner no longer receives power. This unplugging is called “disconnecting.”

To put the above into technical terms, here is the flow of a socket’s use.

1. The socket sits, listening for an incoming connection.
2. When a connection is made, the socket is capable of sending and receiving data to the connected device.
3. The client disconnects from the socket.
4. The socket again begins listening for incoming connections.

The above is fine and dandy if you will ever only have a single vacuum cleaner. But what happens, as often does in the world of networking, when you have many devices that want to connect to the same server? The most basic answer is to create many sockets. That is the answer to the problem, but there is a catch to it which makes it a little more complicated. That catch is called “ports.” A port is a number in which your socket will be listening to. Only one socket can listen to any port on a server at any given time. If another socket attempts to listen on the same port, the operating system will throw an error. You may have heard of “port 80″ for website traffic, or “port 21″ for file transfer traffic. These are the numbers on which the server listens for incoming clients. It would not work to create many sockets listening on many ports, because your clients would never know what ports were already being used by other clients and what ports were not. So, how do you overcome this problem?