Push design

Everything in the communication has time limit

In push design, one of the bigger challenge is to make sure that both server and client side are storing the data/request into a "queue" and then to be handle when some threads are free to process the data/request. By using the "queue", the client/server can end the current method call after the data/request has been queued for later processing.

In the WCF context, you have two types of design to process the data/request:

1. using "function" design (works like "DateTime.Now" which returns the value immediately) - for example, the client sends "current time" command to the server and expecting the server responding (almost) immediately at the end of the calls.

2. using "callback" design - for example, the client sends "current time" command to the server and does not wait for the server respond. Instead, the server will send the current time through callback.

Both designs have pros and cons and it all depends on your need.

- The "callback" design allows the server to take it's precious time to prepare the necessary data for the client. In case the server is busy or the resources were blocked, it just have to wait until those resources were freed up. It also allows the server to schedule the process later. Upon completion, the server will make callback to the client. This is acceptable if it is not a real-time system.

- The "function" design - the client is always waiting for the result and it needs it now. By using this design, your server is running on deadlock risk (i.e., competing for the resources and locked the resource that other client is asking for). Since all the clients want it now, the deadlock will occur as soon as the same resources were requested by multiple clients. Of course, the deadlock can be avoided with proper locking mechanism.

Even with WCF, the connection will get disconnected

This is not true if you have full control over the server and client. WCF allows the system administrator to tune the "keep alive" time limit. Just in case you don't have the full server access, you need to do something to keep the connection alive.


This can be done by sending NOOP command (i.e., a dummy command that does not perform any action) from client to the server - this will keep the connection alive. In case the connection has broken, you just need to re-establish it.

To send the NOOP command repeatedly, you just need a System.Threading.Timer object which queuing the NOOP command in every 1 or 2 seconds.

How to get the updated data - Push VS Pull

In a client and server environment or cloud environment, your program often requires to monitor the updates on the server. There are two ways to catch the updates: either using a Push or Pull design.

• Push design - with this design, when there is an updates happened, the server will notify the client program. The design will be more complicated (in both client program and server program) as compared to the Pull design.
• Pull design - with this design, the client program will continuously query the server for the updates. Of course, this design is very simple but it comes with a bigger costs (in terms of bandwidth and server processing power) when the number of connections grow.

In order to serve more client connections and reducing the bandwidth consumption, you will have to implement the Push design.

Using socket or web socket to implement the push design:

• This is one of the basic element to implement the push design. So, you must learn how to write socket program. With .Net, you may use WCF (Windows Communication Foundation) to implement this idea but you still need to learn the technical details of what is all about socket and how it works with different configuration.
• Imagine that user A key in a new blog post throught a website and then all the followers will be notified within a few seconds. In this case, the server will send a signal (either using TCP or UDP) to the "online users" (i.e., the user must run a client program and sitting down in the computer to wait for the incoming signal). The preferred way to send the signal is using UDP which you can find lots of information about TCP vs UDP.
• Other than how to send the signal, one of the challenge is the how secure is your data when it is travelling from the server to the client or vice versa. Of course, with WCF, you have the choice of choosing different configuration. In other platform (other than .Net), you will might have to implement the security over the socket communication using SSL/TLS. Just to share with you that you can implement SSL/TLS in Python easily.
• I guess we are quite lucky with the modern programming languages because most of the modern programming langauges able to support asynchronous design with a few keywords changes. We need to learn about async programming as well or otherwise the server program will not be able to scale-up.

Errors that appear in the WCF client app...

I was setting a new server to host my WCF app and I hit the wall with the following error messages. I spent 2 days in solving this problem. I guess, many people is wondering how to resolve these interesting errors.

• The server has rejected the client credentials.
• The socket connection was aborted. This could be caused by an error processing your message or a receive timeout being exceeded by the remote host, or an underlying network resource issue. Local socket timeout was '00:00:59.9687500'.
• The communication object, System.ServiceModel.ServiceHost, cannot be used for communication because it is in the Faulted state.

I have developed a WCF solution in WinForm which allows you to comment out certain settings in the server and client so that you can reproduce the above mentioned error message.

  https://github.com/lauhw/WcfWinForm

Please beware that if you are running the WCF server and client in the same computer, the above error might not appear until you run them in a separate computer.

In a nutshell:

1. Both server and client config file must have the same settings in the "Binding" record. This includes the "security mode".
2. The "identity" settings must be the same in both server and client config file.
3. In the live environment, make sure you remove the "MEX" endpoint unless you want anyone to be able to query the interface.
4. Don't forget to open the port in the firewall.

In case you are hitting the same error mentioned above, the fastest way to solve this problem is to run the test WCF solution (as mentioned above). Make sure that the test solution works. After that, compare the differences in app.config between the test solution and your solution.

Hope you don't have to spend 2 days to solve the configuration problem. ;)

Controlling the page access permission

For most of the website that requires user logon, there are three types: (1) the system administrators (2) system users and (3) the page that is accessible without logon to the website.

The website will show the functions base on the current user type. For example, system administrator will be able to create user account, updating system settings. For system user, they will be able to access the data entry screen, generate reports. Both user types requires to access different features in the system.

In the design option, we may implement with one of the following security strategy:

• The features are turn on/off which depends on the permission that has been assigned to the user. With this strategy, the "user" has many "permissions" (i.e., one-to-many relationship).
• The features are turn on/off which depends on the user falls in which user group. With this strategy, you can have one user in one group or multiple groups (i.e., many-to-many relationship).
• The simplest way is to add a field in the "user" record to identify it's "user type" (either system administrator or system user). Plus either one of the above strategy. With this design, you will be able to come out with a complex security design that can cater most of the requirements.

In ASP.net, you can implement the first and second strategy easily with either the built-in ASP.net user/role framekwork or show/hide the menu options. I guess most of the websites were implemented in this way.

The most interesting strategy is the third option and the implementation is powerful yet simple. You need to develop three page classes which inherits from Page class. Namely "AdminPage",  "UserPage" and the third one is PublicPage (for public access such as "login" page and "contact us" page).

The detail implementation of the in the AdminPage is to ensure that the current user type is system administrator in OnInit event.

public class AdminPage : Page
{
        protected override void OnInit(EventArgs e)
        {
            base.OnInit(e);

             // if the user has not logged on, jump to "access deny" page.           
             // if current user is not  "system admin", jump to "access deny" page.
  
        }
}

For the UserPage, we don't want the system administrator to access it (this depends on the requirments) :

public class UserPage : Page
{
        protected override void OnInit(EventArgs e)
        {
            base.OnInit(e);
           
             // if the user has not logged on, jump to "access deny" page.
             // if current user is not  "system user", jump to "access deny" page.
  
        }
}

Once the above page classes are ready, you just need to change your ".aspx.cs" parent class to one of the above. By using the Object Oriented Programming, your developer colleagues will be able to find out which page is for admininstrator, user and public (just right click on the AdminPage and choose Find All References). This also reduce the developer comments in the ".aspx.cs" and increase the maintainability.

By inheriting the web page from different parent page class, there is a "gray" area which you are not sure if it should be PublicPage or UserPage. In this case, you might need to declare a new hybrid page class for it and limit the contents between the "public" and "user". But, for me, I prefer to move the "contents" from the page to "user control" (i.e., ".ascx") and limit the contents base on current user type. Then, I create two pages: one inherits from PublicPage and the other from UserPage. By using user control, I'm able to have the page for single audience and I'm able to handle it easily.

ImageButton (asp.net) failed to work in IE10

When you are running your asp.net website (.net 3.5) in IE10 with some ImageButton-s together with the ScriptManager, you might have a chance in triggering the following error:

Sys.WebForms.PageRequestManagerServerErrorException input string was not in a correct format

To resolve this, you need to add the following script after the end of the "Form" HTML tag.

<script type="text/javascript">
    Sys.WebForms.PageRequestManager.getInstance()._origOnFormActiveElement = Sys.WebForms.PageRequestManager.getInstance()._onFormElementActive;
    Sys.WebForms.PageRequestManager.getInstance()._onFormElementActive = function (element, offsetX, offsetY) {
        if (element.tagName.toUpperCase() === 'INPUT' && element.type === 'image') {
            offsetX = Math.floor(offsetX);
            offsetY = Math.floor(offsetY);
        }
        this._origOnFormActiveElement(element, offsetX, offsetY);
    };
</script>

For more details, please read the following URL:

http://stackoverflow.com/questions/13299685/ie10-sending-image-button-click-coordinates-with-decimals-floating-point-values

Web Service (asmx) vs Handler (ashx)

In ASP.NET environment, it comes with quite extensive way of handling the web request. There is Page class (aspx), Handler (ashx), Web service (asmx), Web service in WCF (asmx), etc. It's all upto the developer to decide the best way to write their program.

Let's compare the Web Service (asmx) and Handler (ashx):

• With Web Service you can run your Visual Studio and add the web service as web reference. This will create the necessary classes for you. With web service, the serialization and deserialization of the data object will be handle by .Net framework. This simply means that you can work with Web Service without having deep knowledge in the "background" process.
• With Handler you must find out what is the parameter to be pass to the handler. No code generator that is able to help out over here. It provides very basic features to serve the request and you will have to serialize/deserialize your data objects manually (you may use JavaScriptSerializer to deal with the JSON data). It does not limit you from returning the data in JSON, XML or CSV format. It's all depend on your design.

With Web Service, it saves you from lots of codes in the serialization process. With Handler, it allows to develop low level request & response. Both has it's own pros and cons.

There is no conclusion on which one is better. It goes back to you to choose which one is suitable for the project that you work on.

Session is not missing in the Handler

I still remember the first time that I'm developing with generic handler (.ashx) and found out that the session is missing. This is because the handler implements only the basic feature (as compared to Page class).

In order for the AJAX call accessing the session information, your handler must implement the following interface:

    System.Web.SessionState.IRequiresSessionState

OR

    System.Web.SessionState.IReadOnlySessionState

That's all you need.