views:

91

answers:

3

I have a class that uses 'System.Net.Sockets.Socket' directly for network comunication, and currently I use the following two interfaces to break dependency on the Socket class :

public interface ISocketListener
    {
        void Listen(int backlog);

        ISocket Accept();

        void Bind(EndPoint endpoint);               
    }

public interface ISocket
    {
        void Connect (EndPoint ep);

        Stream CommunicationStream { get; }

        void Close();

        void Close(int timeout);

        void Shutdown();
    }

In the production implementation I just redirect all the method calls to the private Socket object. In testing environment I use a MemoryStream as the comunication 'pipe' between the sockets. Since I have little experience in the subject, some questions appeared in my head while writing tests : Are there any 'formal' good practices in testing this kind of software? When doing integration testing, how do I test the performance of this server in multiple connections/high latency situations (more specifically, how to simulate these situations)? Why there are asynchronous versions of Socket.Accept/Socket.Receive? Can I replace the asynchronous methods for handling their synchronous versions in separate threads?

+1  A: 

I'm not familiar with the socket object. However, I have done some research about testing. It looks like you're on the right track. Writing interfaces that can refer to either the actual objects that will be used in production or test objects is generally considered good practice. This pattern is known as "Dependency Injection".

I don't know how the socket works, but what you can do for testing purposes is create a new test object to use in place of the socket you want to test. This test object can simply call Thread.Sleep(x) to add some simulated latency before returning data.

Edit: I would also like to point out that you're going to have to be very careful to ascertain exactly where the network latency occurs in your code so that when you inject the artificial latency, you add it to the same place in the code where it would occur in the real world.

Rice Flour Cookies
Do you mean split some binary data into chunks and send each chunk using Thread.Sleep intervals? Thats a possible solution but I'm unsure if that simulates high latency correctly, I might give it a try though. What about handling multiple concurrent connections? how would that be handled?
Thiado de Arruda
What I'm saying is that since you've written your own interface, you should be able to write a test object that simulates the latency and use it in your test environment. I can't say anything of the details of how the latency should be simulated.
Rice Flour Cookies
+1  A: 

You could simulate high latency by creating a proxy server to sit inbetween your connection, then you can just add a delay when re-sending the data.

Chris Almond
You mean a mocked proxy server? Could you give an example?
Thiado de Arruda
A: 

Are there any 'formal' good practices in testing this kind of software?

I can speak to this but I'm sure there is some good information here on stack or out in the wild.

When doing integration testing, how do I test the performance of this server in multiple connections/high latency situations (more specifically, how to simulate these situations)?

For a simple start write some test and logging routines, running them on a separate box, that hammered the server with a verity of requests...including nonsensical ones. Running log4net on both would also be helpful. Introducing some lag could be done, as already mentioned, via a sort of proxy...a box that sits between the client and server. The client points to the proxy and the proxy modifies the data...delay, change packet order, etc....sends to to the server...reverse and repeat. As a slight aside...I would avoid Thread.Sleep(...). Better to use something like this :

lock (timelock) { Monitor.Wait(timelock, TimeoutInMilliseconds); }

...asynchronous versions of Socket.Accept/Socket.Receive? Can I replace the asynchronous methods for handling their synchronous versions in separate threads?

You have many options, asynchronous methods, plain old threading, the threadpool, the TPL, etc. The best choice is application specific.

Here is an Asynchronous Server Socket Example from the MSDN entry on sockets.

As luck would have it....the O'Reilly book: C# 4.0 in a Nutshell has an excellent set of TCP Server examples that cover both asynchronous/threaded methods in blocking/non-blocking manifestations. Here is one of the examples....

  public class Server
  {
    public void Serve(IPAddress address, int port)
    {

      TcpListener listener = new TcpListener(address, port);
      listener.Start();
      while (true)
      {
        TcpClient c = listener.AcceptTcpClient();
        Task.Factory.StartNew(Accept, c);
      }
    }

    void Accept(object clientObject)
    {
      using (TcpClient client = (TcpClient)clientObject)
      {
        using (NetworkStream n = client.GetStream())
        {
          byte[] data = new byte[5000];

          int bytesRead = 0; int chunkSize = 1;

          while (bytesRead < data.Length && chunkSize > 0)
          {
            bytesRead +=
              chunkSize = n.Read /// Read is blocking
                (data, bytesRead, data.Length - bytesRead);
          }

          Array.Reverse(data);
          n.Write                /// Write is blocking
            (data, 0, data.Length);
        }
      }
    }
  }

Hope this is helpful.

P.S. Get a copy of C# 4.0 in a Nutshell...tis good.

Rusty
Thanks for the tips, I'm going to take a look at the book. I think setting up another machine just to do some integration tests is a bit of overkill. I want tests to be fast and run them all by pressing a button
Thiado de Arruda
You can certainly do your testing from the same box..but..you will then be sharing the same network stack. So your results will be a bit skewed. It is not a deal breaker, you should just be aware of possible side effects...enjoy.
Rusty