Have you ever run in to a problem where you are attempting to troubleshoot a network connectivity issue with a network capture utility and seen only the 3 way handshake? This will happen if you are using Netmon 2.x, Netmon 3.x, Wireshark, Ethereal and most other network capture utilities.

It is relatively common knowledge that this will happen when TCP Chimney offload is enabled but disabling it via the registry or netsh sometimes doesn’t always resolve the problem. TCP Chimney offload enables TCP/IP processing to be offloaded to network adapters that can handle the TCP/IP processing in hardware. The use of TCP Chimney offload causes traffic to be delivered at a lower layer of the TCP/IP stack than we listen on with most network capture utilities.

The initial troubleshooting for this type of issue is to turn off TCP Chimney Offload via Netsh as follows. The benefit of this is that it does not require a reboot.

To turn off TCP Chimney by using the Netsh.exe tool, follow these steps:

1. Click Start, click Run, type cmd, and then click OK.
2. At the command prompt, type Netsh int ip set chimney DISABLED and then press ENTER.

However, if this does not change what is shown in a network capture, you should then move forward with disabling all of the features of the Scalable Network Pack as documented in Knowledge Base article 948496 – “An update to turn off default SNP features is available for Windows Server 2003-based and Small Business Server 2003-based computers”.

To manually disable RSS, NetDMA and TCP Offload, follow these steps:

1. Click Start , click Run , type regedit , and then click OK .
2. Locate the following registry subkey: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
3. Right-click EnableTCPChimney , and then click Modify.
4. In the Value data box, type 0, and then click OK.
5. Right-click EnableRSS, and then click Modify.
6. In the Value data box, type 0, and then click OK.
7. Right-click EnableTCPA, and then click Modify.
8. In the Value data box, type 0, and then click OK.
9. Exit Registry Editor, and then restart the computer.

Disabling Chimney with netsh and changed the registry values above will allow you to see all the traffic in most cases but not always. You may also need to look at the features related to TCP Chimney offload available on the Network card. To access these options, choose the configure button on the general tab of the adapters properties. This will bring up a Window similar to what is displayed below. The Advanced tab is where the changes will be made.

The configurable options available vary depending on how the vendor implements the driver for Windows. Many network cards have features including Receive Side Scaling, TCP Checksum Offload and TCP Large Send Offload. Disabling the offload features of the network card will allow you to view all of the traffic in many cases where disabling the scalable network pack features in the OS doesn’t work. You should refer to the vendor’s documentation for specific steps on how to disable these features.

As a last resort you may have to disable chimney from a hardware perspective. Refer to the vendor’s documentation for specific information on how to disable offload features. Possible ways to do this vary, and may include settings on the NIC, jumpers on the motherboard, and/or configuration in System BIOS.

- Michael Vargo

One of the common problems I have seen is to bulk upload data to a SQL Server database. If you have the flexibility to directly run your code in SQL, you have a ton of options. But let's say that you have to massage the data before you throw it in to the database, then you have to really know your SQL (well to do it in SQL).

Let's say you have to read data from an RSS feed, parse it and then load it into SQL. Let's assume further that this feed updates every 2 hours. It would be a trivial task to write a C# app that reads and parses the feed. One crude way to upload this data would be to do a single row insert for each data element. This would be terribly inefficient. The other option would be to use .Net framework's SqlBulkCopy class.

The basic template would be something like

private void WriteToDatabase()
{
    // get your connection string
    string connString = "";
    // connect to SQL
    using (SqlConnection connection = 
            new SqlConnection(connString))
    {
        // make sure to enable triggers
        // more on triggers in next post
        SqlBulkCopy bulkCopy = 
            new SqlBulkCopy
            (
            connection, 
            SqlBulkCopyOptions.TableLock | 
            SqlBulkCopyOptions.FireTriggers | 
            SqlBulkCopyOptions.UseInternalTransaction,
            null
            );

        // set the destination table name
        bulkCopy.DestinationTableName = this.tableName;
        connection.Open();

        // write the data in the "dataTable"
        bulkCopy.WriteToServer(dataTable);
        connection.Close();
    }
    // reset
    this.dataTable.Clear();
    this.recordCount = 0;
}

The above code snippet shows you the API usage. But before you actually do that, you need to follow a couple of steps to setup your data table.

First, let's look at a simple record structure (as reflected in C# class):

using System;
using System.Data;
using System.Configuration;

/// <summary>
/// Summary description for MyRecord
/// </summary>
public class MyRecord
{
    public int TestInt;
    public string TestString;

	public MyRecord()
	{
	}

    public MyRecord(int myInt, string myString)
    {
        this.TestInt = myInt;
        this.TestString = myString;
    }
}

Now, let's start dissecting the class that we will use to upload the data:

using System;
using System.Data;
using System.Collections.Generic;

using System.Data.SqlClient;
using System.Configuration;
using System.IO;

namespace SqlExamples.FileLoader
{
/// <summary>
/// Summary description for BulkUploadToSql
/// </summary>
public class BulkUploadToSql
{
    private List<MyRecord> internalStore;

    protected string tableName;
    protected DataTable dataTable = new DataTable();
    protected int recordCount;
    protected int commitBatchSize;

Note that we have an internal List data structure as well as the DataTable. This is redundant and you can avoid using the internalStore if your application does not need to massage the data before it's sent to SQL.

I then define 2 private constructors. The reason is that we want to use the factory pattern to return our object to the caller.

    private BulkUploadToSql(
        string tableName, 
        int commitBatchSize)
    {
        internalStore = new List<MyRecord>();

        this.tableName = tableName;
        this.dataTable = new DataTable(tableName);
        this.recordCount = 0;
        this.commitBatchSize = commitBatchSize;

        // add columns to this data table
        InitializeStructures();
    }

    private BulkUploadToSql() : 
        this("MyTableName", 1000) {}

Note that we set the commit batch size. This is a very important factor that needs to be fine tuned for your database. What this defines is the number of records that we would send in one shot to the database.

The next step is to Initialize the data table with columns that reflect the actual table structure.

private void InitializeStructures()
{
    this.dataTable.Columns.Add("TI", typeof(Int32));
    this.dataTable.Columns.Add("TS", typeof(string));
}

I then provided a factory method to load data into my internal structure from a data source. In the example code below, I use a Stream, but this can be any data source from where you wish to populate your data.

public static BulkUploadToSql Load(Stream dataSource)
{
    // create a new object to return
    BulkUploadToSql o = new BulkUploadToSql();
    
    // replace the code below
    // with your custom logic 
    for (int cnt = 0; cnt < 10000; cnt++)
    {
        MyRecord rec = 
            new MyRecord
            (
            cnt, 
            string.Format("string{0}", cnt)
            );
        o.internalStore.Add(rec);
    }

    return o;
}

This would make sure that our class is properly initialized and loaded with data. Once the caller has a valid object, they can now "Flush" the data as shown below:

public void Flush()
{
    // transfer data to the datatable
    foreach (MyRecord rec in this.internalStore)
    {
        this.PopulateDataTable(rec);
        if (this.recordCount >= this.commitBatchSize)
            this.WriteToDatabase();
    }
    // write remaining records to the DB
    if (this.recordCount > 0)
        this.WriteToDatabase();
}

private void PopulateDataTable(MyRecord record)
{
    DataRow row;
    // populate the values
    // using your custom logic
    row = this.dataTable.NewRow();

    row[0] = record.TestInt;
    row[1] = record.TestString;

    // add it to the base for final addition to the DB
    this.dataTable.Rows.Add(row);
    this.recordCount++;
}

In the example above, the call to Flush() actually massages the data (and at the same time loads it into the actual data table). As I mentioned before, you can actually skip this step if your application does not require massaging.

As a example of an app that uses this class:

using System;
using System.Collections.Generic;
using System.Text;
using SqlExamples.FileLoader;
using System.IO;

namespace DemoApp
{
class Program
{
    static void Main(string[] args)
    {
        using (Stream s = 
            new StreamReader(@"C:\TestData.txt"))
        {
            BulkUploadToSql myData = 
                BulkUploadToSql.Load(s);
            myData.Flush();
        }
    }
}
}

As always, this is JUST demo code to explain a concept. This is NOT production quality code and please make sure to follow the coding guidelines in your team.

Happy coding....