theburningmonk.com

Came across an inter­est­ing ques­tion on Stack­Over­flow on how one might be able to throt­tle the num­ber of requests across mul­ti­ple servers run­ning the same WCF ser­vice. So for instance, if you have 3 servers sit­ting behind a load bal­ancer and for one rea­son or another you can only allow 5 requests to be made against the ser­vice at any moment in time and any sub­se­quent requests need to be queued until one of the pre­vi­ous requests finish.

For those of you famil­iar with the pro­gram­ming con­cept of a sem­a­phore, you might see that the above require­ment describes a sem­a­phore which applies across mul­ti­ple machines. A quick search on Google for ‘cross-machine sem­a­phore’ reveals sev­eral imple­men­ta­tions of such sys­tem using memcached.

Nat­u­rally, a dis­trib­uted cache is a good way to go about imple­ment­ing a cross-machine sem­a­phore IF you are already using it for some­thing else. Oth­er­wise the over­head and cost of run­ning a dis­trib­uted cache clus­ter purely for the sake of a cross-machine sem­a­phore makes this approach a no-go for most of us..

Instead, you could eas­ily imple­ment a sem­a­phore ser­vice to pro­vide the same func­tion­al­ity to mul­ti­ple WCF clients as the bog-standard Sem­a­phore class do to mul­ti­ple threads. Such a ser­vice might look some­thing like this:

[ServiceContract]
public interface ISemaphorService
{
    [OperationContract]
    void Acquire();

    [OperationContract]
    void Release();
}

[ServiceBehavior(InstanceContextMode = InstanceContextMode.PerCall)]
public class SemaphoreService
{
    private readonly static Semaphore Pool = new Semaphore(5, 5);

    public void Acquire()
    {
        Pool.WaitOne();
    }

    public void Release()
    {
        Pool.Release();
    }
}

This approach will intro­duce a sin­gle point of fail­ure as for sem­a­phore ser­vice to work cor­rectly it’ll need to be run­ning on a sin­gle machine. If you were to use this approach you should have build up some infra­struc­ture around it so that you can recover swiftly if and when the server run­ning the sem­a­phore ser­vice goes down.

In terms of the client code you should make sure that Release is called for every Acquire call, so would be a good idea to put a try-finally block around it:

var client = new SemaphoreServiceClient();

try
{
    // acquire the semaphore before processing the request
    client.Acquire();

    // process request
    ...
}
finally
{
    // always remember the release the semaphore
    client.Release();
}

One of the less known aspect of the Dat­a­Con­tract­Se­ri­al­izer is its depen­dency on the order in which fields are seri­al­ized and deserialized.

As this arti­cle points out, the basic rules for order­ing include:

• If a data con­tract type is a part of an inher­i­tance hier­ar­chy, data mem­bers of its base types are always first in the order.
• Next in order are the cur­rent type’s data mem­bers that do not have the Order prop­erty of the DataMem­ber­At­tribute attribute set, in alpha­bet­i­cal order.
• Next are any data mem­bers that have the Order prop­erty of the DataMem­ber­At­tribute attribute set. These are ordered by the value of the Order prop­erty first and then alpha­bet­i­cally if there is more than one mem­ber of a cer­tain Order value. Order val­ues may be skipped.

The prob­lem is that when the inbound data is not ordered accord­ingly the fields which are ‘out of order’ will not be dese­ri­al­ized as high­lighted by this Stack­Over­flow ques­tion. Though this is unlikely to hap­pen as the seri­al­izer will take care of the cor­rect order­ing for you, unless like jhersh you are attempt­ing to man­u­ally cre­ate some data for test purposes.

Part­ing Thoughts…

See­ing as the Dat­a­Con­tract­Se­ri­al­izer is also depen­dent on the order­ing of the fields in the seri­al­ized type (albeit not trans­par­ent to you and well taken care of almost all the time) I have long been tempted to try out the Pro­to­col Buffers wrap­per for .Net which are meant to be much faster and more com­pact because it doesn’t seri­al­ize the names of the prop­er­ties unlike the DataContractSerializer.

For those of you who aren’t aware of it, pro­to­col buffers is the binary seri­al­iza­tion used by Google for most of its data com­mu­ni­ca­tions. In order to use the protobuf-net seri­al­iza­tion you need to explic­itly spec­ify the order in which your prop­er­ties should be serialized:

[DataContract]
public sealed class Test1
{
    [DataMember(Name="a", Order=1, IsRequired=true)]
    public int A { get; set; }
}

[DataContract]
public sealed class Test2
{
    [DataMember(Name = "b", Order = 2, IsRequired = true)]
    public string B { get; set; }
}

[DataContract]
public sealed class Test3
{
    [DataMember(Name = "c", Order = 3, IsRequired = true)]
    public Test1 C { get; set; }
}

And inject a new behav­iour to the WCFmethod to use the new serializer:

[ServiceContract]
public interface IFoo
{
    [OperationContract, ProtoBehavior]
    Test3 Bar(Test1 value);
}

Oh, such temptation…

Ref­er­ences:

Stack­Over­flow ques­tion – WCF data con­tract, some fields do not serialize

MSDN – Data mem­ber order

protobuf-net — Is it quick?