Click here to Skip to main content
11,796,393 members (71,526 online)
Click here to Skip to main content

WCF Killer

, 11 Feb 2011 CPOL 30.7K 635 59
Rate this:
Please Sign up or sign in to vote.
A simple high performance drop-in TCP protocol handler for client server communications with POCO objects and no messy proxy classes like WCF.


This is a piece of code that I have been using for a long time, which is simple to use, doesn't impose any additional work, and gets the job done for client server communications using the TCP protocol. You just include a single file in your project and get all the benefits.

Kudos to Yuen Chiu So for writing the original article found here (dotnettcp.aspx). The original article only handled strings; my article extends that to a level which you can use in your own client server application which must transfer the detailed objects of data. I have also tweaked and tested the code to get the maximum performance and stability out of it (see the performance test section).


This code came about after using named pipe communication for a long time and having the following problems, although arguably named pipes are faster at data transfer:

  • Named pipes require authentication on connection to a computer, which is very limiting in non-domain computers and requires the user to enter a valid system user and password on the destination computer to even work.
  • The named pipe implementation I was using was very large, code wise.

So for the above reasons, I set about creating a replacement which would fit the following requirements:

  • Simple to use in code, with minimal configuration.
  • Multi-threaded so it can scale to hundreds of simultaneous users.
  • Does not impose additional code "proxies" and "contracts" and should work with normal serializable objects.
  • Does not require computer level authentication, which is implicit in using the TCP protocol as it is handled at a lower level than the OS (unlike named pipes).
  • Flexibility to implement your own authentication on top of it.
  • Handle large data transfer objects, e.g., 3 MB data packets.

The test application


Run the solution, and you will get a command line application like in the picture above. Press the 'S' key for server mode, 'C' key for client mode, and anything else for automatic mode which will start sending requests to the server. The application is hard coded to send and receive on the IP address which is the local system; you can change this to test on a real network with different computers.

The data.cs file contains the sample POCO data object which is hard coded to a 3 MB size; you can change this to test smaller and larger data packets (see the performance test section).

Using the code

To use the code, first you must create your data packets like the ones below:

public class Packet
    public Packet()
        data = new byte[3*1024*1024]; // 3 mega byte
    public byte[] data { get; set; }

    public string Message { get; set; }
    public string Username { get; set; }
    public string Password { get; set; }
    public Guid SessionGuid { get; set; }

    public new string ToString()
        return Message;

public class ReturnPacket
    public bool OK { get; set; }
    public string Message { get; set; }

As you can see, the data structures are normal classes and not proxies; you also must put the Serializble attribute on the class so the .NET serializer can work with it.

For the server code, you do the following:

NetworkServer ns = new NetworkServer(99, new ProcessPayload(serverprocess));
// will listen on port 99


private static object serverprocess(object data)
    Packet dp = data as Packet;
    if (dp != null)
        return HandlePacket(dp);
    Console.WriteLine("message not recognized");
    return new ReturnPacket();

private static object HandlePacket(Packet dp)
    ReturnPacket ret = new ReturnPacket();
    if (dp.SessionGuid == Guid.Empty)
        // Authenticate username and password possibly with LDAP server
        // check sessionguid valid -> if not return failed
    ret.OK = true;
    ret.Message = "your msg : " + dp.Message + "\r\nreturn from server " + DateTime.Now;
    return ret;

As you can see, it is pretty straightforward and simple.

For the client side, you do the following:

NetworkClient nc = new NetworkClient("", 99);
// send to local host on port 99

Packet p = new Packet();
ReturnPacket ret = nc.Send(p) as ReturnPacket;

What is up to you

The following is up to you to implement yourself as you see fit for your own application:

  • Data Packet Definitions: what you want to send over the wire
  • Authentication: handling authentication is up to you if you need it
  • Session Management: related to authentication is session management

Performance tests

Here is the performance test results done on an AMD K625 1.5ghz, 4GB RAM, Windows 7 Home, win rating of 3.9 Notebook (CPU usage above 88%):

Number of simultaneous clients Data packet size Chunk size Request in 10 secs
5 ~12kb 32kb 12681
5 ~12kb 16kb 12291
5 ~12kb 4kb 11089
5 ~3mb 4kb 141
5 ~3mb 16kb 207
5 ~3mb 32kb 220

As you can see, the best performance is with a CHUNK_SIZE of 32 KB for both small and large data packets. You can go higher, e.g., 64 KB, but you get diminishing returns, and possibly (I don't know for sure), you may have problems with some switches and routers in the network as they might block large packet sizes.

Points of interest

I have put the network server code in a NETSERVER conditional compilation block so you will have to add that to your project definition. There is a Config class in the NetWorkClient.cs file which has some predefined options that I have tweaked to maximum performance; one note worthy option is NUM_OF_THREADS which is how many threads the server creates to handle a request. The default is 10, which should be enough for most applications; I have used it for handling 50+ clients applications in real world circumstances.

What you can do at home or further directions

Below is a list of possibilities you can do at home if you feel adventurous:

  • Progress Events: events to publish the progress of data for the client application to hook on to and display UI for.
  • Encrypted Communication: using SslStream instead of NetworkStream for encrypted data transfer.
  • LDAP Authentication of User: check the username and password embedded in the packet with an LDAP server (see the comments in the test app).
  • Session Management: handle client sessions and authenticated connections (see the comments in the test app).
  • Maybe replace BinarySerializer: for greater performance, you could look at the protocol serializer from Google which is incredibly fast and compact.


  • Initial release: Feb. 12, 2011.


This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


About the Author

Mehdi Gholam
United Kingdom United Kingdom
Mehdi first started programming when he was 8 on BBC+128k machine in 6512 processor language, after various hardware and software changes he eventually came across .net and c# which he has been using since v1.0.
He is formally educated as a system analyst Industrial engineer, but his programming passion continues.

* Mehdi is the 5th person to get 6 out of 7 Platinums on CodeProject (13th Jan'12)

You may also be interested in...

Comments and Discussions

GeneralRe: Prohibits?! Pin
Sergey Alexandrovich Kryukov30-Jun-12 20:03
mvpSergey Alexandrovich Kryukov30-Jun-12 20:03 
GeneralRe: Prohibits?! Pin
Frederico Barbosa28-Nov-12 1:24
memberFrederico Barbosa28-Nov-12 1:24 
QuestionWhat do you mean by WCF Killer Pin
aamironline12-Feb-11 2:09
memberaamironline12-Feb-11 2:09 
AnswerRe: What do you mean by WCF Killer Pin
Mehdi Gholam12-Feb-11 4:36
memberMehdi Gholam12-Feb-11 4:36 
AnswerRe: What do you mean by WCF Killer Pin
Sergey Alexandrovich Kryukov30-Jun-12 16:31
mvpSergey Alexandrovich Kryukov30-Jun-12 16:31 
GeneralMy vote of 5 Pin
Basarat Ali Syed11-Feb-11 23:58
memberBasarat Ali Syed11-Feb-11 23:58 
GeneralNice article. Pin
PHS24111-Feb-11 23:20
memberPHS24111-Feb-11 23:20 
GeneralRe: Nice article. Pin
Mehdi Gholam12-Feb-11 0:44
memberMehdi Gholam12-Feb-11 0:44 
Glad you liked it.

A few kb to 150mb is a wide range, although in my experience most of the data transfer is around 12kb range with the occasional someone who calls for all the data which could easily get to 300mb ( it took the app 5 min to transfer and load the data in the ui grid). For this reason I had to optimize the dataset transfer with surrogates (search the internet for it) which reduced the same payload size to 30mb.

I will create a test with variable data and see, thanks for pointing that out.

Like to know more of your war stories...
Its the man, not the machine - Chuck Yeager

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

| Advertise | Privacy | Terms of Use | Mobile
Web03 | 2.8.151002.1 | Last Updated 12 Feb 2011
Article Copyright 2011 by Mehdi Gholam
Everything else Copyright © CodeProject, 1999-2015
Layout: fixed | fluid