The council that recently purchased our CAT kiosk made a short movie for their local tv station, if you are interested in seeing the CAT in action

Click here

The CAT piece is 1 minute 29 seconds into the movie.

Following up from my recent post on our CAT kiosk deployment.

Here is a link to the councils own article

Yesterday was a big day for Rich and myself we successfully deployed our CAT software to our first customer in conjunction with our video conferencing partner First Connections.  The software allows members of the public to interact with their local council almost as if they are with them in person.  Allowing members of the public to access services from rural locations.

The kiosk utilises two screens, one being a touch screen.  The touch screen is used to visit specific council web sites, or to start a video call with a member from one of the council help desk team.  Once in a video call the council representative can help complete specific council forms including taking passport style photos with the built in HD camera and customers signatures using a high resolution LCD signature pad.

All built using .NET 4 and Windows Embedded.

Must be screen cast Thursday, another screen cast posted to RSK on Concurrent Data Structures in .NET 4

RSK screen casts

Just uploaded a new screencast on async and await keywords due to be introduced in C# 5.

Rock Solid Knowledge Screencasts

One parallel pattern that required some work with base .NET 4 was parallel pipe lines.  The CTP release of the Parallel Dataflow extensions, makes this trivial now.  I’m intending to do a screencast really soon to show this action, but in the mean time try it out for yourself you can download it from here

What do most engineers want to do, “Build Things”. Regular training classes are good at introducing new technology, but what if you want to take it further; to stretch and motivate your senior developers. This was the requirement that our major investment bank client presented to Rock Solid Knowledge the co-developed solution was to produce a Coding Challenge…

The Training Day One

The first day was spent with a deep dive into Silverlight; all teams had prior knowledge of WPF. The focus of the day was to effectively demonstrate the differences and similarities of the two technologies, giving the teams the ability to deliver a high quality Silverlight solution to match the code challenge requirements document.

The Challenge Day Two

The three person teams, of senior developers, spent the next 24 hours straight building a working product to the supplied specification. Not only did this test their ability to apply the new technology but demonstrated who ships and who doesn’t. Failing to organise is clearly highlighted when you only have a short period of time to deliver.

The Assessment Day Three

After working nearly flat out for 24 hours the teams submitted their solutions to be assessed by Rock Solid Knowledge. Initial marks were given, with each team then given a technical grilling on their solution to provide feedback on what was good and bad.

The Winner

The winning team all received iPads, a satisfactory reward for all their hard efforts and our client introduced a new technology in a vibrant and compelling way.

If this has wetted your appetite a more detailed write up can be downloaded from here or if you would just simply like to know how we could bring this experience to your company contact us by clicking here

I have just found myself answering essentially the same question 4 times on the MSDN WCF Forum about how instances, threading and throttling interact in WCF. So to save myself some typing I will walk through the relationships here and then I can reference this post in questions.

Instancing
WCF has 3 built in instancing models: PerCall, PerSession and Single. They are set on the InstanceContextMode on the ServiceBehavior attribute on the service implementation. They relate to how many instances of the service implementation class get used when requests come in, and work as follows:

• Single – one instance of the implementation class is used for all requests
• PerCall – every request gets its own instance of the implementation class
• PerSession – this is the slightly odd one as it means every session gets its own instance. In practical terms it means that for Session supporting bindings: NetTcpBinding, WSHttpBinding, NetNamedPipeBinding, etc, every proxy gets an instance of the service. For bindings that do not support session: BasicHttpBinding, WebHttpBinding, we get the same effect as PerCall. To add to the confusion, this setting is the default

Concurrency
By default WCF assumes you do not understand multithreading. Therefore, it only allows one thread at a time into an instance of the service implementation class unless you tell it otherwise. You can control this behavior using the ConcurrencyMode on the ServiceBehavior; it has 3 values:

• Single – this is the default and only one thread can get into an instance at a time
• Multiple – any thread can enter an instance at any time
• Reentrant – only makes a difference in duplex services but means that an inbound request can be received from the component you are currently making a request to (sounds a bit vague but in duplex the role of service and client are somewhat arbitrary)

Interaction
Now these two concepts are different but have some level of interaction.

If you set InstanceContextMode to Single and ConcurrencyMode to Single then your service will process exactly one request at a time. If you set InstanceContextMode to Single and ConcurrencyMode to Multiple then your service processes many requests but you are responsible for ensuring your code is threadsafe.

If you set InstanceContextMode to PerCall then ConcurrencyMode Single and Multiple behave the same as each request gets its own instance

For PerSession ConcurrencyMode Multiple is only required if you want to support a client sending multiple requests through the same proxy from multiple threads concurrently

Threading
Unless you turn on ASP.NET Compatibility, WCF calls are processed on IO threads in the system threadpool. There is no thread affinity so any of these threads could process a request. The number of threads being used will grow until the throughput of the service matches the number of concurrent requests (assuming the server machine has the resources to match the number of concurrent requests). Although the number of IO threads is capped at 1000 by default, if you hit this many then unless you are running on some big iron hardware you probably have problems in your architecture.

Throttling
Throttling is there to ensure your service is not swamped in terms of resources. There are three throttles in place:

• MaxConcurrentCalls – the number of concurrent calls that can be made – under .NET 4 defaults to 16 x number of cores
• MaxConcurrentSessions – the number of concurrent sessions that can be in in flight – under .NET 4 defaults to 100 x number of cores
• MaxConcurrentObjects – the number of service implementation objects that are in use – defaults to the sum of MaxConcurrentCalls + MaxConcurrentSessions

In reality, depending on whether you are using sessions or not, the session or call throttle will affect your service the most. The object one will only affect your service if you set it lower than the others or you do something unsual and handle the mapping of requests to objects yourself using a custom IInstanceContextProvider

You can control the throttle values using the serviceThrottling service behavior which you set in the config file or in code

Red Gate have announced that from the next release in March no more free versions of Reflector.

http://www.red-gate.com/products/dotnet-development/reflector/announcement