PokeIn provides various ways to make your server side application efficiently communicate to the client side by extending the capabilities of Ajax technology. Although Ajax is way far efficient approach to use for most of the cases in comparison to old school page post, there are some points need to be addressed for better efficiency. Anyway, the most efficient point of Ajax technology must be updating user’s view without loading all the stuff on a page and grabbing the updates from users’ view in same way.

Mostly, server-client data communication carries user specific updates and for this reason, server actions are user specific. Even though the updates are mostly user specific, there are some points shared by user groups therefore handling them by same server side objects may improve the efficiency of the entire application. So we asked the question that what if our application needs shared streaming for the specific user groups? PokeIn offers two different grouping choices you may implement into your application regarding to task. Please notice that, you are free to use both of these approaches in the same application but mostly it is not a necessary.

Joint Feature

As you know, PokeIn automates .NET to JS, JS to .NET and .NET to .NET remote method access and handles all these communication by targeting server side object instances from the client side or targeting specific client(s) from the server side. We realized that if we provide object instance sharing by user groups, it may boost both performance and server side resource usage efficiency thus we create joint feature.

Joint feature simply shares object instances among the given users. For example, all the users in the same chat room may share same joint name and so same shared message object. On the other hand, these users may want to chat with others thus the default user specific object instance handles this task. At this point, imagine two independent objects; the first one is shared among the all joint members and the second one is user specific.

First of all, we have to add a parameter into PokeIn connection request to define joint name. To set a joint name for a view, you just extend PokeIn connection URL as shown below;

<script src=’Handler.aspx?ms=connect&j=Room1’ ></script>

The given definition j=Room1, marks this user as the member of “Room1” joint. To make this name dynamic, you could set it like <%=joint_name%>

Besides normal connection events like OnClientConnected, there are joint events when you set a joint name as shown above.

static void CometWorker_OnFirstJoint(ConnectionDetails details, string jointId, ref Dictionary<string, object> classList)

        {

            classList.Add("Shared", new MySharedClass(details.ClientId, jointId));

        }

  CometWorker’s OnFirstJoint event fires when the first connection request for a specific joint name received by the server. The object instance of MySharedClass lives until there is no active connection left for the given joint name. When the last user is disconnected from the joint, PokeIn releases the shared object and shuts down the joint until a new request is received.

static void CometWorker_OnClientJoined(ConnectionDetails details, string joinedToClientId, ref Dictionary<string, object> classList)

        {

            classList.Add("Individual", new MyIndividualClass(details.ClientId));

        }

        On the other hand, OnClientJoint event fires for each joint connection request and this is the place for defining client specific object instances. Each “individual” object instance life is limited to client’s connection period.

                 CometWorker.SendToJoint provides functionality to send a message to the joint members and it is a good choice to handle shared tasks for the joints inside the shared object instance.

                 Joint feature is a logical implementation choice for shared sessions. For example, if you are going to implement a shared document editing application or multiplayer game then you must consider using joint feature.

Group Feature

What if your users have common message blocks but there is no need for shared object instances. Think of a stock market application. Grouping users by the quotes they are watching may help you to reduce the overhead on the server side. Thus we implement grouping feature.

CometWorker.Groups.PinClientID(clientId, "group name");

                 When you call above line, PokeIn checks first is there any existing group active and create if it is not. Then subscribe the given client id into to group. So, when you call SendToGroup method and give the name of this group as a first parameter, all the subscribed clients get the message.

                Please notice that you don’t have to deal with “unpinning” client from the group when it disconnects or removing group definition from the application when there is no client left inside the group. PokeIn handles all these tasks.

                Sample projects are available from http://www.pokein.com/Help/Samples.aspx