Protocol Buffers

As you may or may not know I’ve been rather heavily involved in helping with the protobuf-csharp-port for the past year under the pseudonyms grigand and rogerk. Recently we’ve released version 2.4.1.473 which had two major features I’m very happy with.

The first of these, the newly added option ‘service_generator_type’, allows generation of service interfaces or blocking service stubs. This is really the powerhouse behind the new project I launched ‘protobuf-csharp-rpc‘ which provides a full RPC implementation built on top of the RpcLibrary.

The second major new thing is the extracted interfaces for ICodedInputStream and ICodedOutputStream along with the Google.ProtoBuffers.Serialization assembly to support reading and writing messages to/from XML, JSON, IDictionary<,> and others. There is even a few little helpers for building http/rest protocols to support protobuf, xml, json, and uri-encoded data.

Over the coming weeks I hope to explore some of these new things with you and share them here. For now, much of this remains dedicated to my own ‘extension’ project for the rpc services layer using the RpcLibrary.

BPlusTree and Custom ISerializer Implementations

BPlusTree, Home, Projects, Protocol Buffers

Aug 222012

Almost the first thing you need to create a BPlusTree is going to be the key/value serializers which are implementations of the ISerializer<T> interface. They are also going to be one of the things that can make or break your first impressions of using the BPlusTree. A descent performing implementation is going to be important in order to get the most out of your BPlusTree. Aside from performance alone, there is one other area of concern, that of the semantic interface.

Implementing the ISerializer<T> Interface

First let’s take a quick look at the interface definition for those that are not familiar with it.

public interface ISerializer<T>
{
    void WriteTo(T value, Stream stream);
    T ReadFrom(Stream stream);
}

Simple enough, right? Well, not exactly. It seems that one thing is not obvious from this interface. The ‘stream’ parameter is not constrained in any way. One could seek to an offset they should not be at, or read past the end of the item they are suppose to be reading. Exceptions are also a bad idea here since it can prevent you from reading the tree. So the following guidelines should be used when implementing this interface for use with the BPlusTree:

Always use an immutable class, a value type, or ensure that references to the class inserted/updated/fetched are not modified.
When writing values you should try to avoid any case for throwing an exception.
Always use a length-prefix or termination value to prevent reading more data than was written for this value.
When reading you should only throw exceptions when you believe the data has been corrupted.
Never read more data than was written for this record as this will cause subsequent values to be corrupted.
Do not seek or use positional information from the stream, assume it is either append-only writing, or forward-only reading.

Primitive Serialization

For most primitive types you should not need to write one, instead use the The PrimitiveSerializer class (declared in CSharpTest.Net.Serialization). The PrimitiveSerializer class has static properties for many of the serializers you will need for primitives. These are all written using little-endian byte ordering for numeric values.

If you need to write a compact format there is another class to help you with numeric encoding. The VariantNumberSerializer class exposes serialization for protocol buffer-like variant encoding of integer values. Basically this can be used to store positive integer values in more compact format than using the PrimitiveSerializer.

Neither of these provide an array serializer for anything other than a byte[]. This can often be a desired type so here is a generic implementation that will serialize arrays given a serializer for the item type.

public class ArraySerializer<T> : ISerializer<T[]>
{
    private readonly ISerializer<T> _itemSerializer;
    public ArraySerializer(ISerializer<T> itemSerializer)
    {
        _itemSerializer = itemSerializer;
    }

    public T[] ReadFrom(Stream stream)
    {
        int size = PrimitiveSerializer.Int32.ReadFrom(stream);
        if (size < 0)
            return null;
        T[] value = new T[size];
        for (int i = 0; i < size; i++)
            value[i] = _itemSerializer.ReadFrom(stream);
        return value;
    }

    public void WriteTo(T[] value, Stream stream)
    {
        if (value == null)
        {
            PrimitiveSerializer.Int32.WriteTo(-1, stream);
            return;
        }
        PrimitiveSerializer.Int32.WriteTo(value.Length, stream);
        foreach (var i in value)
            _itemSerializer.WriteTo(i, stream);
    }
}

Using Protocol Buffers with the BPlusTree

Protocol buffers make an excellent way to serialize data for the BPlusTree. They are compact, fast, and can be extended/modified over time without having to rewrite the records. Due to this I highly recommend using protobuf-csharp-port to generate the classes you will use. In addition to the serialization benefits mentioned this library is also built upon immutable types with builders. This is very important for the accuracy of the data since the BPlusTree makes no guarantees about when the instance will be serialized and it may use the same instance multiple times when reading. The following serializer will provide you a generic implementation that can be used with the protobuf-csharp-port library (NuGet Google.ProtocolBuffers).

using CSharpTest.Net.Serialization;
using Google.ProtocolBuffers;
internal class ProtoSerializer<T, TBuilder> : ISerializer<T>
    where T : IMessageLite<T, TBuilder>
    where TBuilder : IBuilderLite<T, TBuilder>, new()
{
    private delegate TBuilder FactoryMethod();
    private readonly FactoryMethod _factory;

    public ProtoSerializer()
    {
        // Pre-create a delegate for instance creation, new TBuilder() is expensive...
        _factory = new TBuilder().DefaultInstanceForType.CreateBuilderForType;
    }

    public T ReadFrom(Stream stream)
    {
        // Use Build or BuildPartial, the later does not throw if required fields are missing.
        return _factory().MergeDelimitedFrom(stream).BuildPartial();
    }

    public void WriteTo(T value, Stream stream)
    {
        value.WriteDelimitedTo(stream);
    }
}

What about using protobuf-net? This is also very easy to implement and would be the preferred way of code-first serialization (no proto description, just a .NET class/struct). As we did with the protobuf-csharp-port you must length-prefix the messages. Avoid using the IFormatter implementation in protobuf-net since this has a semantic incompatibility with BinaryFormatter and other implementations (it is not length prefixed and reads to end-of-stream). Here is a generic class for serialization using the protobuf-net’s static Serializer class:

public class ProtoNetSerializer<T> : ISerializer<T>
{
    public T ReadFrom(Stream stream)
    {
        return ProtoBuf.Serializer.DeserializeWithLengthPrefix<T>(stream, ProtoBuf.PrefixStyle.Base128);
    }
    public void WriteTo(T value, Stream stream)
    {
        ProtoBuf.Serializer.SerializeWithLengthPrefix<T>(stream, value, ProtoBuf.PrefixStyle.Base128);
    }
}

WCF replacement for cross process/machine communication

Home, Protocol Buffers, RpcLibrary

May 152012

I ran across another post of someone looking to get rid of WCF on StackOverflow today. The post titled “WCF replacement for cross process/machine communication” goes into the typical complaints about configuration of WCF. I actually think this is the least of the issues I’ve had with WCF. Whatever your reason for looking to abandon WCF, this post is for you. A step-by-step walk-through to get up and running with protobuffers over Win32 rpc.

Step 1 – Gathering dependencies

For this post I’m going to be using VStudio 2008. The primary reason is to show the explicit use of NuGet rather than depending on Visual Studio to do it for us. Now let’s get started. Start by creating a new project in Visual Studio, for this I’m going to use a simple command-line application named “SampleProtoRpc”.

After you have created the project, right-click the project and select “New Folder” and type the name “Depends”. Now visit the NuGet project page and download the “NuGet.exe Command Line bootstrapper”. It should be a single file, “NuGet.exe”. Place this file in the newly created “Depends” directory. From a command-prompt, run NuGet.exe to ensure that you are up and running.

Now right-click the project and select the “Properites” from the bottom. In the properties window, click the “Build Events” tab on the left. In the “Pre-build event command line:” text box enter the following text:

"$(ProjectDir)Depends\NuGet.exe" INSTALL Google.ProtocolBuffers.Rpc -OutputDirectory "$(ProjectDir)Depends" -ExcludeVersion -Version 1.11.1016.3

You can update the version to the latest by checking the current version at http://nuget.org/packages/Google.ProtocolBuffers.Rpc. The reason to use a fixed version is to prevent NuGet from constantly checking with the server to see if it has the latest version. By pinning the version number NuGet.exe will make a quick check and continue if it exists.

Click “Build” and view the Output window, it should contain something like the following text:

------ Build started: Project: SampleProtoRpc, Configuration: Debug Any CPU ------
"E:\Projects\Templates\SampleProtoRpc\Depends\NuGet.exe" INSTALL Google.ProtocolBuffers.Rpc -OutputDirectory "E:\Projects\Templates\SampleProtoRpc\Depends" -ExcludeVersion -Version 1.11.1016.3
Attempting to resolve dependency 'CSharpTest.Net.RpcLibrary (≥ 1.11.924.348)'.
Attempting to resolve dependency 'Google.ProtocolBuffers (≥ 2.4.1.473)'.
Successfully installed 'CSharpTest.Net.RpcLibrary 1.11.924.348'.
Successfully installed 'Google.ProtocolBuffers 2.4.1.473'.
Successfully installed 'Google.ProtocolBuffers.Rpc 1.11.1016.3'.
SampleProtoRpc -> E:\Projects\Templates\SampleProtoRpc\bin\Debug\SampleProtoRpc.exe
========== Build: 1 succeeded or up-to-date, 0 failed, 0 skipped ==========

Lastly we need to add the dependencies to the project. Right-click the “References” folder in the project and select “Add References…”. Click on the “Browse” tab in the resulting “Add Reference” dialog box. For each of the following files navigate to the directory and select the file:

Depends\Google.ProtocolBuffers\lib\net20\Google.ProtocolBuffers.dll
Depends\CSharpTest.Net.RpcLibrary\lib\net20\CSharpTest.Net.RpcLibrary.dll
Depends\Google.ProtocolBuffers.Rpc\lib\net20\Google.ProtocolBuffers.Rpc.dll

Don’t worry about these being ‘net20′ assemblies, it will work fine in 3.5. If you insist upon native 4.0 images, the first two packages contain net40 versions; however, the Google.ProtocolBuffers.Rpc does not at this time. You will need to pull the source and build a 4.0 version for that library.

Step 2 – Defining a Protocol

Now that we have a project containing the correct dependencies we need to add a protocol definition file. This is a very easy format to write in, if you need help see the Google Protocol Buffers Language Guide. For now let’s get started by right-clicking the project, and selecting “Add” -> “New Item…”. Select the “General” tab on the left, and then pick the “Text File” option from the right-hand list. In the “Name” field, enter “Sample.proto” and click the “Add” button.

Once you have created the file, select “File” -> “Save As…” from the menu. Next to the “Save” button click on the drop-down arrow and choose “Save with Encoding”. Answer “Yes” when prompted to overwrite the file. From the “Encoding:” list, choose the option “US-ASCII – Codepage 20127″ near the end of the list and then click “OK”.

Now we can type a protocol buffer definition in this file. For now we are going to use the following:

package Sample;
option optimize_for = SPEED;

message MyRequest {
  required string message = 1;
}

message MyResponse {
}

service MyService {
  rpc Send (MyRequest) returns (MyResponse);
}

And this will be our first service. To generate the source, we are going to add another pre-build event. Right-click the project and select “Properties” again. On the “Build Events” pane add the following line:

"$(ProjectDir)Depends\Google.ProtocolBuffers\tools\ProtoGen.exe" --proto_path="$(ProjectDir)\" -output_directory="$(ProjectDir)\" -cls_compliance=false -service_generator_type=IRPCDISPATCH "$(ProjectDir)Sample.proto"

You should now be able to build the project successfully. Once completed, right-click the project and choose “Add” -> “Existing Item…”, then select the “Sample.cs” that should appear next to the “Sample.proto” file we created. Admittingly this is a crufty integration at best.

If you are not opposed to it, I would recommend using CmdTool.exe with a configuration similar to this example. CmdTool.exe is available in one of these downloads, you just download, run “CmdTool.exe Register” and save the configuration example in the same directory as the project. That’s about it, you now have all the source generated to do the work.

Step 3 – Implementing the Service

Before we can go much further we must implement our service interface. Right-click the project and add a new Class file so we can create our implementation, I just called mine “Implementation”. The interface has already been defined for us, it’s name will be our service’s name prepended with an ‘I’. Here is a first-pass implementation that simply writes the message to the console.

    class Implementation : IMyService
    {
        #region IMyService Members
        public MyResponse Send(MyRequest myRequest)
        {
            using (WindowsIdentity user = WindowsIdentity.GetCurrent())
            {
                Console.WriteLine("{0} says: {1}", user.Name, myRequest.Message);
                return MyResponse.DefaultInstance;
            }
        }
        #endregion
    }

Step 4 – Setting up the Listener

Time to start playing with our server-side listener. For this example we are going to allow lrpc, tcp, or named pipes. The static IID defines the interface we want to talk to. We can host several interfaces from this process, but this example will only use one. You will notice we create the generated server proxy “MyService.ServerStub” by handing it an implementation of the IMyService interface. This server stub can then be used to create the RpcServer instance. Once we add at least one protocol and call StartListening we are ready to receive calls. The setup is trivial, so without further explanation here is our new ‘Program’ class:

    class Program
    {
        static readonly Guid IID = Marshal.GenerateGuidForType(typeof(IMyService));

        static void Main(string[] args)
        {
            switch (args[0].ToLower())
            {
                case "listen":
                    {
                        using (RpcServer.CreateRpc(IID, new MyService.ServerStub(new Implementation()))
                            .AddAuthNegotiate()
                            .AddProtocol("ncacn_ip_tcp", "8080")
                            .AddProtocol("ncacn_np", @"\pipe\MyService")
                            .AddProtocol("ncalrpc", "MyService")
                            .StartListening())
                        {
                            Console.WriteLine("Waiting for connections...");
                            Console.ReadLine();
                        }
                        break;
                    }
            }
        }
    }

Step 4 – Sending a Message

Now that we have a working server we need to write a client. The reason for the Main() method above to switch on arg[0] for ‘listen’ is that we are going to use the same program for a client. The client case statement below adds support for an LRPC client call:

                case "send-lrpc":
                    {
                        using (MyService client = new MyService(
                            RpcClient.ConnectRpc(IID, "ncalrpc", null, "MyService")
                            .Authenticate(RpcAuthenticationType.Self)))
                        {
                            MyResponse response = client.Send(
                                MyRequest.CreateBuilder().SetMessage("Hello via LRPC!").Build());
                        }
                        break;
                    }

Once we have added this switch case to the Main routine we wrote we now run one process with the ‘listen’ argument, and another one with the ‘send-lrpc’ argument. We should see the following output in the server process:

Waiting for connections...
DOMAIN\user says: Hello via LRPC!

You may now create two additional case labels, one for “send-tcp”, and one for “send-np”. The only difference between them will be the parameters to the RpcClient.ConnectRpc() api. For TCP/IP we will use RpcClient.ConnectRpc(IID, “ncacn_ip_tcp”, @”localhost”, “8080″), and for named-pipes we would use RpcClient.ConnectRpc(IID, “ncacn_np”, @”\\localhost”, @”\pipe\MyService”). Go ahead and fill those in or not at your choosing.

Step 5 – Authentication

By default the RPC server will allow any user (even anonymous users) to connect. This may work for your needs, this may not. Usually you will want to impersonate the caller and then verify they have access to some resource or are a member of a specific group, etc. To do this in a generic way so that we do not have to place the impersonation code in each method we are going to implement the Google.ProtocolBuffers.IRpcServerStub interface. So let’s create a new class now called Impersonation and it’s going to look a lot like the following:

    class Impersonation : IRpcServerStub
    {
        private readonly IRpcServerStub _stub;

        public Impersonation(IRpcServerStub stub)
        {
            _stub = stub;
        }

        public IMessageLite CallMethod(string methodName, ICodedInputStream input, ExtensionRegistry registry)
        {
            using(RpcCallContext.Current.Impersonate())
            {
                return _stub.CallMethod(methodName, input, registry);
            }
        }

        public void Dispose()
        {
            _stub.Dispose();
        }
    }

Once that has been added we will update our server’s listen routine as follows:

                case "listen":
                    {
                        using (RpcServer.CreateRpc(IID, new Impersonation(new MyService.ServerStub(new Implementation())))
                            .AddAuthNegotiate()
                            ... etc ...

Now every call into every method of MyService implementation on the server will be impersonating the client user. The Rpc layer will also ensure that they are NOT an anonymous user.

Zipping it all up…

Server Options: There are numerous extensibility points on the server and client. There are a few worth covering here. The following is a brief outline of the most important configuration options.

RpcServer.EnableMultiPart() – Allows unlimited message lengths to be received over tcp/np connections. By default Windows limits these to around 1mb. To circumvent this limitation the server and client can be configured to send messages in multiple parts. Both client and server must enable this for this to work, and doing so will enable server-side connection state.
RpcServer.ExceptionDetails – An enumeration value that determines how much exception detail to return to the client. The default, FullDetails, returns all information in the exception including the stack trace.
RpcServer.ExtensionRegistry – Allows registration of proto-buffer ‘extensions’ on both your service and on the transport messages defined in csharp_rpc_messages.proto. This can be used as a side-channel to flow information from the client to server and back again.
RpcCallContext.Current

– This class provides context information about the caller, protocol, authentication, etc.

RpcSession.EnableSessions()

– Enables session state, accessed via RpcCallContext.Session for the current call.

Client Options: The following controls the client options:

RpcClient.EnableMultiPart() – Allows unlimited message lengths to be sent over tcp/np connections. By default Windows limits these to around 1mb. To circumvent this limitation the server and client can be configured to send messages in multiple parts. Both client and server must enable this for this to work, and doing so will enable server-side connection state.
RpcClient.ExceptionTypeResolution – This enumeration controls the exception type resolution when an exception is returned from a server. The default, OnlyUseLoadedAssemblies, will only resolve types that are defined in assemblies that have already been loaded into the client process.
RpcClient.ExtensionRegistry – Just as for the server, this allows proto-buffer ‘extensions’ to be registered and used when receiving response messages.
RpcClient.CallContext – Provides access to the call context instance associated with this connection. Used with the extension registry this allows you to customize side-channel communications between the client and server.

Connection Caching
It should be noted that it is acceptable and generally useful to cache the RpcClient connection; however, you should be aware that a connection can be closed. RpcClient connections will not retry a failed call and will not attempt to reconnect to a server once disconnected. Due to this it is advisable that if you are caching client connections you should create an implementation of Google.ProtocolBuffers.IRpcDispatch. Delegate the actual RpcClient.ConnectRpc() call and configuration to this object so that it can reconnect at will. Finally use this object as as the parameter to the MyService() constructor instead of directly using the RpcClient.ConnectRpc() result.

Download the Sample RPC Project
The project zip file is completely stand-alone. Just extract the contents and open the solution to build.

How to build a multi-protocol REST service with protocol buffers, xml, and json in 10 minutes or less using protobuf-csharp-port

Home, Protocol Buffers

Nov 222011

In this post we are going to explore some great new features introduced in the latest release of the protobuf-csharp-port project. We are going to build both an IIS service to handle requests as well as a sample client. Let’s get started.

Prerequisites
Let’s start by fetching a copy of the protobuf-csharp-port binaries. We can manually download these and unpack them, use NuGet installed in VS2010, or download the NuGet Bootstrapper. I’m going to use the later approach and download NuGet.exe and run the following command:

C:\Projects\ProtoService>NuGet.exe install google.protocolbuffers -x
Successfully installed 'Google.ProtocolBuffers 2.4.1.473'.

Service Definition
With our only dependencies out of the way we are going to need to define some messages and a service. We will start with a new project in visual studio, for ease of demonstration I’ve created an ASP.NET project. To create our service definition we are going to create an empty text file and save it with a “.proto” extension. Be sure to use the File->Save As… menu on this text file, click the down arrow next to the Save button and select “Save with Encoding…”. Near the bottom choose “US-ASCII – Codepage 20127″. This is required by the protoc compiler as it does not support text BOM (Byte order mark). Now that we have a text file let’s create a message for the request and response and the service using the protobuffer definition language:

package ProtoService;

message SearchRequest {
  required string query = 1;
  optional int32 page_number = 2;
  optional int32 result_per_page = 3;
}
message SearchResponse {
  repeated group Result = 1 {
    required string url = 2;
    optional string title = 3;
    repeated string snippets = 4;
  }
}
message ErrorResult {
  required string error_text = 536870911; //max field-id
}
service SearchService {
  rpc Search (SearchRequest) returns (SearchResponse);
}

Code Generation
Now with this saved to “ProtoService.proto” we can run the ProtoGen.exe command-line tool we downloaded with NuGet earlier. ProtoGen will automatically detect that it has been given a “.proto” text file and run the protoc.exe compiler from the same directory as ProtoGen.exe. If you’re including files and setting options defined by google or the csharp port you will need to have the google directory from {Package}\content\protos copied to the location of your proto files. Since this is a stand-alone proto and not including others we don’t need to create a directory structure. Ready to build, let’s run ProtoGen now to create our generated code:

C:\Projects\ProtoService>Google.ProtocolBuffers\tools\ProtoGen.exe -service_generator_type=IRPCDISPATCH ProtoService.proto

The service_generator_type tells the ProtoGen what type of service classes/interfaces we are interested in, the value IRPCDISPATCH generates both interfaces and client/server stubs. There are lots of other options both for protoc and protogen, running ProtoGen.exe /? will list all of them. In addition this can be done directly from VStudio 2005~2010 via the CmdTool.exe integration described here for ProtoGen.exe.

Project References
Now we should find that ProtoService.cs has been created for us. Let’s now add this generated source file to our project and reference the two assemblies we need. Both of our required dependencies are located in Google.ProtocolBuffers\lib\net35, called Google.ProtocolBuffers.dll and Google.ProtocolBuffers.Serialization.dll. After we have added the two references and the generated source file we should able to compile the project. Note: if you get some warnings about CLSCompliant you can either attribute your project as CLSCompliant(true) or add the option “-cls_compliance=false” to the protogen.exe command line above.

Service Implementation
The first code we will write will be our service implementation. The code generator has defined an interface for us to implement called ISearchService. Let’s stub out that implementation now in a class called ServiceImplementation:

class ServiceImplmentation : ISearchService
{
    public SearchResponse Search(SearchRequest searchRequest)
    {
        // Create the response builder
        return SearchResponse.CreateBuilder()
            // Add a result to the response
            .AddResult(
                SearchResponse.Types.Result.CreateBuilder()
                .SetUrl("http://example.com")
                .Build()
                )
            // Build the result message
            .Build();
    }
}

Of course you’re service implementation will be a lot more complicated than this, but this will suffice for demonstration purposes. Go ahead and build your project and then let’s move on to creating the IIS handler.

IIS Handler
Our IHttpHandler implementation could be reduced to a single line call to HttpCallMethod if we chose. The following implementation adds handling of GET requests by parsing of uri query string values and some rudimentary exception handling.

Uri encoded requests are allowed for simple messages (non-nested simple types) and allow us to test right from a browser. This also allows javascript to use a GET request and pass parameters. The MIME type constant ‘ContentFormUrlEncoded’ is defined as “application/x-www-form-urlencoded” which is also the mime type used by HTML forms. This means that web clients can also simply post an HTML form to the service to execute a method, the constraint of simple types remains for forms as well.

class ServiceHandler : IHttpHandler
{
    public bool IsReusable { get { return true; } }
    public void ProcessRequest(HttpContext context)
    {
        MessageFormatOptions defaultOptions = new MessageFormatOptions();
        // Capture the request stream and content-type
        Stream requestStream = context.Request.InputStream;
        string requestType = context.Request.ContentType;

        if (context.Request.HttpMethod == "GET")
        {
            // If the call is an HTTP/GET, we will use URI encoding and the query string
            requestType = MessageFormatOptions.ContentFormUrlEncoded;
            requestStream = new MemoryStream(Encoding.UTF8.GetBytes(context.Request.Url.Query));
        }

        // Parse the HTTP accept header to determine the content-type of the response
        context.Response.ContentType = (context.Request.AcceptTypes ?? new string[0])
                                       .Select(m => m.Split(';')[0])
                                       .FirstOrDefault(m => defaultOptions.MimeInputTypes.ContainsKey(m))
                                       ?? defaultOptions.DefaultContentType;

        // Create the server-side stub to dispatch the call by method name
        using (IRpcServerStub stub = new SearchService.ServerStub(new ServiceImplmentation()))
        {
            try
            {
                // The URI's last path segment will be used for the method name
                string[] path = context.Request.Url.Segments;
                // Use the extension method defined in Google.ProtocolBuffers.Extensions to process
                // the request and write the response back to the client.
                stub.HttpCallMethod(
                        path[path.Length - 1],
                        defaultOptions,
                        requestType,
                        requestStream,
                        context.Response.ContentType,
                        context.Response.OutputStream
                    );
            }
            catch(Exception error)
            {
                // If something fails we will create an ErrorResult and serialze it with the requested
                // content-type obtained earlier while returning an HTTP 500 error.
                context.Response.StatusCode = (int)HttpStatusCode.InternalServerError;
                ErrorResult.CreateBuilder()
                    .SetErrorText(error.Message)
                    .Build()
                    .WriteTo(defaultOptions, context.Response.ContentType, context.Response.OutputStream);
            }
        }
    }
}

IIS Handler Configuration
The IIS 7x handler configuration is very straight-forward. We are binding the path to be a ‘child’ of our service description proto file “ProtoService.proto”. This, combined with the mimeMap below, allows the user to discover our service definition so that they can interact with it. So it’s time to get working, build the project and update the web.config with the following:

  <system.webServer>
    <staticContent>
      <mimeMap fileExtension=".proto" mimeType="text/plain"/>
    </staticContent>
    <handlers>
      <add name="SearchService" preCondition="integratedMode" verb="GET,POST" path="/ProtoService.proto/*"
           type="ProtoService.ServiceHandler, ProtoService, Version=1.0, Culture=neutral" />
    </handlers>
  </system.webServer>

Getting Results
Make sure you are running in IIS, this will not work in Cassini. Open up your browser (NOT IE) and enter the URL: http://localhost/protoservice.proto/Search?query=asdf You should see the following XML response:

<root>
  <result>
    <url>http://example.com</url>
  </result>
</root>

If you type something that doesn’t make sense, or generates an error, (ie. http://localhost/protoservice.proto/BadMethodName) you will see an error message like this:

<root>
<error_text>Method 'ProtoService.ISearchService.BadMethodName' not found.</error_text>
</root>

Client Proxy
Now that we have a working service, building a simple client proxy for C# binary protobuffers is really easy. First we need an implementation of the client proxy dispatch interface, IRpcDispatch. I’m going to use the WebClient here simply because it’s easy; however, production systems more often use the HttpWebRequest class.

class HttpProxy : IRpcDispatch
{
    readonly Uri _baseUri;
    public HttpProxy(Uri baseUri) { _baseUri = baseUri; }

    public TMessage CallMethod<TMessage, TBuilder>(string method, IMessageLite request, IBuilderLite<TMessage, TBuilder> response)
        where TMessage : IMessageLite<TMessage, TBuilder>
        where TBuilder : IBuilderLite<TMessage, TBuilder>
    {
        WebClient client = new WebClient();
        client.Headers[HttpRequestHeader.ContentType] = MessageFormatOptions.ContentTypeProtoBuffer;
        client.Headers[HttpRequestHeader.Accept] = MessageFormatOptions.ContentTypeProtoBuffer;
        byte[] result = client.UploadData(new Uri(_baseUri, method), request.ToByteArray());
        return response.MergeFrom(result).Build();
    }
}

Once we have this defined we can now instantiate and call the proxy.

SearchRequest result;
SearchResponse result;
using(SearchService svc = new SearchService(new HttpProxy(new Uri("http://localhost/protoservice.proto/"))))
    result = svc.Search(SearchRequest.CreateBuilder().SetQuery("bar").Build());

foreach (SearchResponse.Types.Result r in result.ResultList)
    Console.WriteLine(r.Url);

Alternative Client Formats
This proxy uses protobuffers but it could easily be adapted to use json or xml just by changing the content-type and and accept headers and serializing accordingly. To Serialize a protobuffer message as xml or json the following extensions can be used:

//XML
string xmlResult = client.UploadString(new Uri(_baseUri, method), request.ToXml());
return response.MergeFromXml(
    System.Xml.XmlReader.Create(new StringReader(xmlResult)))
    .Build();

//JSON
string jsonResult = client.UploadString(new Uri(_baseUri, method), request.ToJson());
return response.MergeFromJson(jsonResult).Build();

Lastly there are two more extension methods that can do this by simply providing a stream and a mime-type. This is demonstrated above in the catch block of our http handler. Here are the extension method prototypes that can be used:

public static void WriteTo(this IMessageLite message, MessageFormatOptions options, string contentType,
                           Stream output);

public static TBuilder MergeFrom<TBuilder>(this TBuilder builder, MessageFormatOptions options,
                                           string contentType, Stream input) where TBuilder : IBuilderLite;

Closing Remarks
I’m very biased here since I wrote most of this capability; however, I am constantly amazed at how easy protobuffers are to use. Google’s Protocol Buffers are very powerful and extremely fast. I’ve been using them for two years now and I can’t imagine writing a serialization or remoting solution without them.

Benchmarking WCF compared to Protocol Buffers + RpcLibrary

Home, Protocol Buffers, RpcLibrary

Nov 032011

So now that I’ve finally got around to releasing a protocol built on top of the RpcLibrary I thought it would be fun to re-run some benchmarks. The protocol has been around unreleased for almost a year waiting on some required changes in protobuf-csharp-port which have finally been published in a release. The protocol I’m speaking of, Google.ProtocolBuffers.Rpc, uses protobuffer services and the RpcLibrary to provide a full-featured rpc client/server implementation.

Benchmark Process
For the comparison benchmarks I wanted to demonstrate both the power of the RpcLibrary as well as the efficiency of this protobuffer library. So I built this rpc test-harness that spawns a server process and multiple client processes (5 of them) each using multiple threads (3 each). These 15 threads wait on a global signal until everyone is ready and then run 3 times in succession for a fixed duration of 5 seconds. The total numbers of calls made is then divided by the thread’s running duration to produce a calls-per-second. Since this happens 3 times on 15 threads, there are 45 results per test that are then used to produce a worst, average, and best time.

Benchmark Test Data
Each call passes a single object in and returns a single object as a result. The object is a collection of a ‘sample data’ class that has the following data: 32 bytes of random data, those 32 bytes as a base-64 encoded string, a sequentially incremented integer, a double, and a date-time value. The graph title below indicates the number of these records passed in and out for each call. Zero is used for an empty collection/message to test the transport and dispatch speed while only serializing an empty collection. The test was completed for all transport/protocols for message sizes of 0, 10, and 100 records. At 1000 records the test duration was increased to 50 seconds and only ProtoBuf_LRPC and Wcf_TCP were executed.

Transports & Protocols
Most of the transports and protocols used should be obvious enough by the abbreviation name in the charts below; however, there are a few worth calling attention to. All the Wcf_xxx are in-process hosted WCF listeners including the Wcf_Http test. All the ProtoBuf_xxx tests used the RpcLibrary except the ProtoBuf_Wcf test. The ProtoBuf_Wcf used protobuffer protocol serialization on a WCF/TCP transport. The WCF service was basically just a Stream argument, Stream return prototype. I see a lot of people packing protobuffers over WCF without realizing that serialization is not WCF’s only problem. All the tests ending with “_Auth” are fully secured and authenticated connections.

Results with Empty Messages
The top of the blue bar is the worst run’s average calls-per-second, the top of the red bar is the average of all 45 runs, and the top of the green bar is the best calls-per-second of all 45 runs.

Clearly there is almost no comparison here, WCF is running at 1/20th of the speed of the RpcLibrary! That remember is with a completely empty message. I was actually pleased to see that WCF even completed these tests, the last time I tried in .NET 2.0 (WCF 3.0) it dropped client connections and caused them to timeout. This time around running WCF with the full 3.5 sp1 framework it ran flawlessly even if slowly.

It Only Gets Worse for WTF, err WCF
The next two benchmarks only widen the gap between the RpcLibrary and WCF. With just 10 ‘records’ RpcLibrary + Protobuffers outpaces WCF by 25 times, and at just 100 records that jumps to more like 40 times faster! After that it seems to start to level off, 1000 records averaged 40.8 calls-per-second on protobuffers+Rpc, and WCF averaged only 0.91 calls-per-second. That is still a 45 fold increase in performance and, in IMHO, it’s far more acceptable to execute a round-trip in 24 milliseconds instead of 1.1 seconds.

Summary
So the next time you’re looking to stand up an internal service to talk to on the local machine or within the local intranet you should take a close look at alternatives to WCF. It’s wicked fast and I’ve never seen RPC simply ‘hang’ with a broken connection.

NuGet packaging available

BPlusTree, Building, Home, Library, Projects, Protocol Buffers, RpcLibrary

Oct 182011

A few weeks ago I published NuGet packages for version 1.11.924.348.

I also managed to get protobuf-csharp-port on board. I absolutely live by protobuffers.

Finally I recently published a complete protobuf services rpc layer build on the RpcLibrary and protobuf-csharp-port. Of course much of the code there could be used with any raw transport like WCF, TCP, Named Pipes, etc so check it out. This library is also available on NuGet:

Google.ProtocolBuffers.Rpc

If you haven’t tried NuGet you should look at it. If you manage an open source library you really need to get published there. It has allowed me to publish projects that have dependencies without the need to check those dependencies into source control. This reduces the burden on source control, allows for smaller archives, and makes it easier to upgrade dependencies. So trash the binaries from your source control and get started with NuGet.

csharptest.net