David_Bennett : Indigo

How to turn on debug exceptions with WCF

David_Bennett — Mon, 13 Nov 2006 08:54:00 GMT

It is possible to see exceptions passed back in the messages sent to the service. This makes it a lot easier to debug multi-peer applications. The way to do this is to add into the web.config file the section. You can see in the following config section that the behavior <serviceDebug includeExceptionDetailInFaults="true" /> is defined, this sets up the system to include exception details in the return faults. If you do this set this up, make sure you remove it when you deploy your code into the wild. Finding exception info can be used to find ways to exploit your server based on stack traces.

    <system.serviceModel>
        <services>
            <service name="OneCareStatus.LogUploadService" behaviorConfiguration="UploadServiceBehavior">
                <endpoint address="" contract="OneCareStatus.ILogUploadService" binding="wsHttpBinding" bindingConfiguration="myHttpBinding"/>
            </service>
            <service name="OneCareStatus.FamilySafetyService" behaviorConfiguration="UploadServiceBehavior">
                <endpoint address="" contract="WpcSettings.IWpcSettingsService" binding="wsHttpBinding" bindingConfiguration="myHttpBinding"/>
            </service>
        </services>
        <bindings>
            <wsHttpBinding>
        <binding name="myHttpBinding">
         <security mode="None" />
         <reliableSession enabled="true"/>
        </binding>
            </wsHttpBinding>
        </bindings>
        <behaviors>
            <serviceBehaviors>
                <behavior name="UploadServiceBehavior">
                    <serviceMetadata httpGetEnabled="true" />
                    <serviceDebug includeExceptionDetailInFaults="true" />
                </behavior>
            </serviceBehaviors>
        </behaviors>
    </system.serviceModel>

Duplex calls in indigo beta 1

David_Bennett — Fri, 13 May 2005 21:07:00 GMT

There are two things you need to remember when making a duplex contract under indigo beta 1, the first is that you can only use one way calls on the contract and you also need to specify the callback contract in the main contract.

On the client side to open a call to a duplex contract you need to use the CreateDuplexChannel call on the ChannelFactory which specifies a service to callback on and to get the channel to talk back on on the service side you use the OperationContext.Current.GetCallbackChannel<CallbackContract> call.

Here is the contract to be used:

interface IPong
{
    [OperationContract(IsOneWay=true)]
    void Pong(int n);
}

[ServiceContract(CallbackContract=typeof(IPong))]
interface IPing
{
    [OperationContract(IsOneWay=true)]
    void Ping(int n);
}

The [ServiceContract] attribute has the CallbackContract attrbribute associated with it and this lets you specify the callback contract to use to talk back to the client. If this is specified on a contract then you must use CreateDuplexChannel to open a connection to the channel, using CreateChannel will throw an exception saying that you need to use a duplex contract.

The service will look like this:

[ServiceBehavior]
class PingService : IPing
{
    public void Ping(int n)
    {
        Console.WriteLine("Ping {0}", n);

        if (n < 0)
        {
            OperationContext.Current.GetCallbackChannel<IPong>().Pong(n+1);
        }
        else if (n > 0)
        {
            OperationContext.Current.GetCallbackChannel<IPong>().Pong(n-1);
        }
    }
}

This uses the callback channel to call back onto the client. When the client opens up a channel on the client side it needs to specify an instance of the IPong interface to talk back to. This is the code that will be called and used the the duplex channel request comes in from the service.

class App
{
public void MakeChannel()
{
     PongCallback pong = new PongCallback();
     IPingChannel ping = ChannelFactory.CreateDuplexChannel<IPingChannel>(pong, TcpAddress, TcpBinding);
     using (ping)
     {
         ping.Ping(5);
         Console.WriteLine("Press a key to exit");
         Console.ReadKey();
         ping.Close();
     }
}
}

class PongCallback : IPong
{
    public void Pong(int n)
    {
        Console.WriteLine("Pong {0}", n);

        if (n < 0)
        {
            OperationContext.Current.GetCallbackChannel<IPingChannel>().Ping(n+1);
        }
        else if (n > 0)
        {
            OperationContext.Current.GetCallbackChannel<IPingChannel>().Ping(n-1);
        }
    }
}

Different types of InstanceModes and ConcurrencyModes inside Indigo

David_Bennett — Thu, 21 Apr 2005 22:07:00 GMT

Indigo has five different types of instances modes than be used inside the system. The default liftetime, if none is specified, is PerCall. They are:

PerCall
PrivateSession
SharedSession
Singleton
Well known

The PerCall lifetime means that each time a call comes into the system a new instance is created of the service and a new ServiceSite that is associated with it is created. The second two types of instance lifetime only work when there is a session associated with the channel, a session is created when ReliableMessaging is enabled on the bindings. The PrivateSession lifetime means the instance and site stick around for the entire duration of the session, so this usualy means the duration of the channel. A SharedSession means that the endpoint reference to the service can be generated on the client side by using ResolveInstance(). This endpoint reference can then be passed onto other clients or other channels and used to reference the specific endpoint on the remote side. A singleton means that there will only ever be one of the ServiceSite created on the remote side and this will be used for the entire duration of the servicehost.

The well known lifetime is a variation on singleton where the instance is created before hand and passed into the ServiceHost as a specific instance when it is created. This instance is then used in all cases where the instance is needed to be referenced. A well known instance must have a [ServiceBehavior(InstanceMode = InstanceMode.Singleton)] set on the service.

If the InstanceMode is set to PrivateSession of SharedSession the system will throw an exception when you try and setup a binding on the service side that does not support a session. They do not have a fall back behavior if the incoming channel does not contain a session and will cause an exception to be thrown on the client side.

Creating a custom instance of a Service inside Indigo

David_Bennett — Thu, 14 Apr 2005 22:22:00 GMT

When you setup an Indigo service in the default way, it is not possible to use anything other than the default constructor for creating your object. There are two ways you can setup a custom object to use as your service instance, the first is to use a well known object as the service when you add the endpoint. This means that the instance effectively operates as if it is a singleton, but you control which object it uses as the singleton. To achieve this behavior when you setup a ServiceHost<T> you pass in a T to the constructor.

The second mechanism you can use to setup your own object for the system is that you can hook into the IServiceDispatcher code and return your own instance from the GetInstance call. You can return anything you like from the GetInstance call, but it must conform to the originaly specified contract and must be of the correct type, or the calls will not be made on it.

Some example code of how to hook up the GetObject call follows. You are also informed when an object is Released in case you want to do some pooling. If you hook up the GetObject and ReleaseObject calls you will need to control yourself when the Dispose is called on the objects and any other cleanup that is done on the service instance once it is released.

    [ServiceBehavior(InstanceMode = InstanceMode.PerCall)]
    [CLSCompliant(false)]
    public partial class ServiceCallTest : IInstanceProvider, ISiteInitializer,
IContractBehavior, IServiceTest
    {
        public void Bar(string n)
        {
            System.Console.WriteLine("Bar(" + n + ")");
            return;
        }

        #region IContractBehavior Members

        public void BindProxy(ContractDescription desc, System.ServiceModel.ProxyBehavior proxy)
        {
        }

        public void BindDispatch(ContractDescription desc, System.ServiceModel.DispatchBehavior dispatch)
        {
            dispatch.InstanceProvider = this;
            dispatch.SiteInitializers.Add(this);
        }

        #endregion

        public object GetInstance(ServiceSite site, Message incoming)
        {
            System.Console.WriteLine("GetObject.");
            return new ServiceCallTest();
        }

        public void ReleaseInstance(ServiceSite site, object instanct)
        {
            System.Console.WriteLine("ReleaseObject.");
        }

        public void Initialize(ServiceSite site, Message mess)
        {
            System.Console.WriteLine("Initialize.");
        }
    }

MaxConnections standard bindings and throttling

David_Bennett — Sat, 09 Apr 2005 23:22:00 GMT

Throttling and the standard bindings inside the Indigo CTP allow you to set and control the maximum number of connections coming into the system. This is only settable on a few of the standard bindings, like NetProfileNamedPipeBinding and NetProfileTcpBinding, however the default value for these is 10. So if you are using these bindings and expect your web servive to get much activity you should increase the number.

These bindins also play a part in how security works, security sets up a second parallel connections so if you set your MaxConnections to be 1 and try to connect to the service with a secure channel, it will timeout and not connect.

To set the max connections on the bindings is quite easy, you just do this:

NetProfileTcpBinding frog = new NetProfileTcpBinding();
frog.MaxConnections = 30;

To set the MaxConnections on the host when you setup the ServiceHost class you access the Throttling property and set connection inside there.

ServiceHost<MyService> womble = new ServiceHost<MyService>();

womble.Throttling.MaxConnections = 30;

The throttling value for the MaxConnections property defaults to MaxInt, so it is more likely you will see constraints from the binding themselves than you will from the throttling, unless you setup the throttling yourself of course.

Throttling is done at the ServiceModel level of the system while the bindings are actually down at the channel level, so they tend to operate slightly differently than the ServiceHost throttling. The MaxConnections on the service host is also across all the possible endpoints associated with that service, not just the specific one the binding is aimed at.