Saturday, September 22, 2007

.NET remoting – speed / security

.NET remoting is a guaranteed mechanism of talking between multiple objects in different appdomain. What is appdomain? If you know the difference between managed world and un-managed world then you should have come across appdomains. CLR when started (it will start when the application is being run) will occupy a section of the un-managed memory (we call it un-managed because the developer is responsible for creation and deletion) and makes a section with in it, managed memory. Hence forth whatever objects are being created in the application is run within the managed segment of memory and the whole boundary is termed as appdomain or application domain.

Using remoting the various appdomains can interact/exchange data; this could be in the same machine or machine to machine across firewalls etc.

The design of the remoting could be such that of a client server model. Say if you are designing the provider with interfaces so that their implementation will be inheriting MarshalByRefObject and hence the clients/consumer (which sits in other appdomains) can access the data using the activator methods. There could be some potential issues with respect to security if you expose the interfaces directly, say in my case I have the consumer and the provider sitting in the same machine. And the provider uses certain DLL’s to play with the data. The consumer should be restricted with the data access the provider defines the scope of the data for the consumers, in this case if the provider exposes the interfaces, which could be re-casted.

And also when the interfaces implementation directly inherits MarshalByRefObject then what happens is the consumer gets the actual object each time, this means each time you need to pull a data your request and the connection is going to be really slow, can I overcome it, yes ask for more data at one shot. Dough well I do not know when I have to ask data, say the server/provider gives the data, there will be events raised and you will be monitoring the events and have the data flow back and forth. So in this case what to do?
Yep you got to think of a dataset (ADO.NET) kind off model, pass a duplicate copy each time and let that be a structure (at least in my case) so that all the data that are changed and needs to be shown in the GUI or front end is got as one shot. What happens constantly if the server/provider’s data is changing queue some data wait for some time and then re-send the structure each time, by this mechanism you have the duplicate copy each time. What does that mean? Well when some is taking the actual copy then you are asking the main provider to wait until the consumer is done with the object/data. So you are essentially ending up in a synchronous scenario, has any design be considered a good one if it is synchronous only in normal scenario? We know the answer it is NO, so we have to do it the above way to make it asynchronous. Who ever gets the data or has will not trouble the other. And by doing this we save the multiple clients requests that are waiting to be answered by the provider.

How did we end up like the above design?, what happened was the consumer/provider access model made the whole application slog, just to get a single data and this happened more often when more data is passed. So the pipes have been heavily used and the operation was slow. Though the advantage is we have a thread safe code, but total impact was slow. And the irony was my application is called Extreme tuning utility that means faster performance of the hardware based on the algorithms we run, can this itself ruin the machine’s speed…no ways….So we need to think of faster mechanism as described above. And also not allowing the hackers to interpret the interfaces the way they wanted, remember the re-casting stuff I started in the beginning.

Friday, September 21, 2007

Interfaces Vs Classes

Are you a programmer with decent experience and are you in to .NET then you wouldn't have missed this question interfaces Vs classes. you must have come across this when you do design, or if not at least when you are interviewing. This happens to be one of the very favorite questions among the interviewers.

Initially I had different ways of understanding things and ended up giving different answers based on different reasons. Then I sat down with my senior (Nelson Kidd) in my current work place to understand what the real deal between both is. The below write-up is based on his teaching/inputs to me, a lot is based on our project but still it is very generic and applies to all.

Below you will see more than the common differences like the abstract classes can have implementations but the interfaces cannot, classes have the classes’ typical properties.

Interfaces are the way to mention the contract behavior, where as with classes it is hard to maintain it is like if you are providing API’s and if you are the provider of the API, if you are using interfaces you say it is like these are the behavior and properties. If you are doing the same by the way of classes (all the way inheriting with different provider side implementations) then it is like saying well this is the behavior and properties and also this is the way I am going to implement it. Then when something changes in the API’s end it becomes way to harder if the provider API’s are built based on classes, the consumers need to change the way their code is written. But if it is interface there will be very minimal impact or none in terms of addition of new methods to the interface and it will be a minor impact if something changes/removed. The killer here is the difference in the way the classes has to be inherited to achieve different implementation.

Dough I am not a C# programmer and my code is in C++, then what’s the deal, so you would create various Abstract classes with various pure virtual functions and the classes will implement the methods of the abstract classes. With classes there is a lot of way of messing out with the security/access specifier, that you can use public/private/protected. And you need to develop a document for the API users to understand when a method can be called, what is the context blah blah…so that they can understand how to use your classes.
But the nicer way with interface is that there is no way to get it wrong, I mean by mistake when using classes developers can misuse the access specifier and hence gets things wrong. But with interfaces they are the way they are and the .NET platform will not allow you to mess up with the interfaces, because it works straight things that are allowed are allowed and things that are not are not.

Think from a business angle it all boils down to the contract agreement, when you are developing enterprise wide applications you are often providing some API’s and the contract is signed for that. These API’s are easier to define on the first hand by understanding the requirements without bothering the implementation we can define whole lot of interfaces to it in the first place. So it is using interfaces helps in bridging the gap between requirements and development. The second thing is you do not have the luxury of asking your fellow customers/cross-company developers to change their code it is because you designed the API’s using the classes.

A simple way is to use a factory pattern to give the instance of the implementation of the interface and the caller will be just asking for the interface’s instances. But if the same where a class then there will be many strict design required as opposed to being very informal to the interface implementations and of course multiple interfaces could be implemented. Interfaces be re-casted, hence for security issues on the end (like .NET remoting) use classes, at least wrap the interfaces that you want to expose with the classes wrapping it.

There are different kinds off programmers, some would say this is how you have to do it, and some totally do not care about it unless the end result is fine. The rules are to be broken, but understand when and where you can break, understand the whole problem and give the best solution in terms of your approach and the way you attack, remember some one is paying for you and as long as they see the value in the way you do it, then you are in the right direction; if not it is time to THINK.

Saturday, September 08, 2007

Asynchronous delegates in .NET

Delegates - Delegates are type safe function pointers that are usually used as a enabler of call back mechanism. Delegates are synchronous by default in the .NET environment. Which means when an event is fired and a delegate is invoked, the delegate is completed synchronously. This could be made asynchronous too, but why?
Say for example in my case I have a .NET remoted server which could be connected by various clients and each client that is connecting could send requests and get a response back from the server. So what happens if an event in the server has its subscriptions in the client side, say there are three subscriptions. We know that in a multiple subscription scenario the invocation goes from the first subscriber until the next in a sequential order. And what if an exception gets thrown while in the middle of executing the subscriber's procedure? The others in the subscription list have to wait until the exception is being handled. In this case we would want to make the mechanism asynchronous providing control to the server so that the other clients who are in the queue of being serviced will not be waiting for ever.

Asynchronous delegate