Donnerstag, 7. Februar 2013

Playing around with ZeroMq

Today I was playing around with ZeroMq. I found a nice introduction on the topic for the latest version. In addition to what is written there, here are my findings.

General ZeroMq

ZeroMq is a library based on socket communication. The big advantage in contrast to plain socket programming is, that ZeroMq uses internal queues and enables various message patterns by default while hiding the details.
A central concept in ZeroMq is, surprisingly, the socket. Sockets have a certain type and are usually used in pairs - each pair enables a common communication pattern as:
  • Publish / Subscribe (PUB / SUB)
  • Request / Response (REQ / REP)
  • Push / Pull (PUSH / PULL)
The server, or more generally the most stable peer, opens a socket and binds to it. During the bind an address, aka endpoint, is given to the socket. Multiple other peers can then connect to this socket using the opposite socket type. I. e. for Request / Response the server binds to a REP socket on a certain address and the client connects via an REQ socket to the given address.

The following transport types are supported:





  • inproc
local in-process (inter-thread) communication transport
  • ipc
local inter-process communication transport
  • tcp
unicast transport using TCP
  • pgmepgm
reliable multicast transport using PGM
As you can see, communication is limited to intranet bindings, so there is no way to communicate via http.

As ZeroMq uses internal queues it is generally not important wether a socket is already bound before a client connects or if a client is connected prior to binding a socket. But one address can only be bound to one peer at a time - another binding yields an exception.

Basically all messages are represented as simple plain strings.

Getting Started

I will discuess the most common communication patterns in the following sections. To get started, kick off a new VS Solution and get the clrzmq package using nuget.


Make sure to select "Include prerelease" to get the latest version.

The general usage pattern of the ZeroMq API is always as follows:

  • Creating a ZeroMq Context class by using var ctx = ZmqContext.Create()
  • Create a socket using the context instance by calling var socket = ctx.CreateSocket(socketType)
  • Bind / connect to the socket with a given address by calling socket.Bind("tcp://127.0.0.1:5000") or socket.Connect("tcp://127.0.0.1:5000")
  • Sending / Recieving messages by calling socket.Send(message, encoding) or socket.Receive(encoding)
The following snippet ilustrates this basic protocol:


using (var context = ZmqContext.Create())
{
    using (var socket = context.CreateSocket(SocketType.REQ))
    {
        socket.Connect("tcp://127.0.0.1:5000"); - OR - socket.Bind("tcp://127.0.0.1:5000");

        socket.Send("Hello", Encoding.UTF8); - OR - var msg = socket.Receive(Encoding.UTF8);
    }
}

Request / Response

The server binds to a REP typed socket, the clients connect using a REQ socket. Here is the server code:

using (var context = ZmqContext.Create())
{
    using (var socket = context.CreateSocket(SocketType.REP))
    {
        socket.Bind("tcp://127.0.0.1:5000");
        while (true)
        {
            var recievedMessage = socket.Receive(Encoding.UTF8);
            Console.WriteLine("Recieved message: '{0}'", recievedMessage);
            var replyMessage = String.Format("This is the reply to message '{0}'", recievedMessage);
            Console.WriteLine("Sending reply: '{0}'", replyMessage);
            socket.Send(replyMessage, Encoding.UTF8);
        }
    }
}

The client looks like this:

using (var context = ZmqContext.Create())
{
                
    using (var socket = context.CreateSocket(SocketType.REQ))
    {
        socket.Connect("tcp://127.0.0.1:5000");
        while (true)
        {
            Console.WriteLine("\nEnter message (Enter to quit)");
            var sendMessage = Console.ReadLine();

            if (String.IsNullOrEmpty(sendMessage))
                return;

            Console.WriteLine("Sending message '{0}'", sendMessage);
            socket.Send(sendMessage, Encoding.UTF8);
            var replyMesssage = socket.Receive(Encoding.UTF8);
            Console.WriteLine("Recieved reply message '{0}'", replyMesssage);
        }
    }
}

My findings with Request / Response:

  • For the client does not matter wether the service is up and running when the client starts. 
  • The client blocks at send until the server is present (a timeout can be specified).
  • There is no way of finding out wether the server is present or if at least on client is connected, expect waiting for the timeout to expire.
  • Request and response must come in pairs. To subsequent request fail as well as the response is mandatory.

Push / Pull

This pattern is named Pipeline in the documentation and they use it in a way that there is a source of messages that equally distributes these among all connected peers. The peers do some processing and then sending the results to a third party which is the message sink. The worker peers use two sockets, one to receive messages from the source and one to send messages to the sink. For my personal testing I have chosen an easiser setup with a pushing sender an a pulling receiver.

The server:

private static void Push()
{
    int messageNumber = 0;
    using (var ctx = ZmqContext.Create())
    {
        using (var socket = ctx.CreateSocket(SocketType.PUSH))
        {
            socket.Bind("tcp://127.0.0.1:5000");

            while (true)
            {
                var msg = String.Format("{0}: pushing message {1}", DateTime.Now, messageNumber++);
                Console.WriteLine("Pushing: " + msg);
                socket.Send(msg, Encoding.UTF8);
                Thread.Sleep(1000);
            }
        }
    }
}

And the client:

private static void Push()
{
    int messageNumber = 0;
    using (var ctx = ZmqContext.Create())
    {
        using (var socket = ctx.CreateSocket(SocketType.PUSH))
        {
            socket.Bind("tcp://127.0.0.1:5000");

            while (true)
            {
                var msg = String.Format("{0}: pushing message {1}", DateTime.Now, messageNumber++);
                Console.WriteLine("Pushing: " + msg);
                socket.Send(msg, Encoding.UTF8);
                Thread.Sleep(1000);
            }
        }
    }
}

My findings with Push / Pull


  • Sending on a PUSH socket blocks until at least one pulling client is present (a timeout can be defined).
  • Messages are distributed round-robin to connected peers.
  • As only a single bind to an endpoint is allowed, only one process cann push at a time. 
  • Connecting to a PUSH socket and then sending message yields to lost messages.

Publish / Subscribe

The server binds a PUB socket, the client subscribes via SUB. In contrast to the previous examples the client does not use the Connect method, but the Subscribe / SubscribeAll method. When using Subscribe the client can pass a list of message prefixes it is interested in.

Here goes the server:

private static void Pub(IEnumerable<String> prefixes)
{
    if (prefixes.Count() == 0)
        prefixes = new[] { "Apple", "Microsoft", "Google" };

    var prefixMessageCounter = new Dictionary<String, int>();

    foreach (var prefix in prefixes)
    {
        prefixMessageCounter.Add(prefix, 0);
    }

    using (var ctx = ZmqContext.Create())
    {
        using (var socket = ctx.CreateSocket(SocketType.PUB))
        {
            socket.Bind("tcp://127.0.0.1:5000");

            while (true)
            {
                foreach (var prefix in prefixes)
                {
                    var msg = String.Format("{0}: Message number {1}", prefix, prefixMessageCounter[prefix]++);
                    Console.WriteLine("Publishing: " + msg);
                    socket.Send(msg, Encoding.UTF8);
                    Thread.Sleep(1000);
                }

            }
        }
    }
}

And the client:

private static void Sub(IEnumerable<String> prefixes)
{
    using (var ctx = ZmqContext.Create())
    {
        using (var socket = ctx.CreateSocket(SocketType.SUB))
        {
            if (prefixes.Count() == 0)
                socket.SubscribeAll();
            else
                foreach (var prefix in prefixes)
                    socket.Subscribe(Encoding.UTF8.GetBytes(prefix));

            socket.Connect("tcp://127.0.0.1:5000");

            while (true)
            {
                var msg = socket.Receive(Encoding.UTF8);
                Console.WriteLine("Received: " + msg);
                Thread.Sleep(1000);
            }
        }
    }
}

My findings with Publish / Subscribe

  • If no subscriber is listening the message will get lost.
  • All the subscribers will get all published messages.
  • There is no way to see if someone is subscribed.
  • As only a single bind to an endpoint is allowed, only one process cann publish at a time.
  • Connecting to a PUB socket yields no error but has no effect either.

Some "limitations" and the conclusion

While trying around with ZeroMq a few questions popped out in my mind, and I looked for answers on the web. Finally I came up with the following findings, which may be limitations in some cases:
  • No http communication
  • No way of getting a peers IP-Address on connect
  • No way of seeing if a port is bound or if anyone is connected
Of course all these points have a rationale, which I understand. I write down these points to make it easier to see in which cases using ZeroMq might not be an option: namely if one of the points above is a requirement for you.

On the other hand, when you have the need to quickly implement messaging using a well defined communication pattern, ZeroMq is great. The code is very easy as you can see above. And it is blazing fast. Furthermore there are a lot advanced communication patterns that I have not covered. Consult the ZeroMq documentation for this.

socket.send("Have fun with ZeroMq!", Encoding.UTF8);

Mittwoch, 28. November 2012

Sharepiont item level rights and a fluent Interface

Fluent Interfaces are a common thing nowdays, and evereyone who ever used Linq knows about them. Other products use them as well. But have you ever tried to write on on your own? Lately I did, and I found that there are different ways to do it depending on the situation where you are starting from.

My sceanrio was, that I wanted to implement a solution for running to set item permissions on a sharepoint list item. You need elevated privileges to do that if you are not an admin. Usually, in the ItemAdded event reciever you do it like so:

var item = properties.ListItem;
var web = properties.web;

SPSecurity.RunWithElevatedPrivileges(delegate()
{
   using (SPSite oSite = new SPSite(web.Site.Url))
   {
     using (SPWeb oWeb = oSite.OpenWeb())
     {
       SPList oList = oWeb.Lists.GetList(item.ParentList.ID, false);
       SPListItem oItem = oList.Items.GetItemById(item.ID);

       oItem.BreakInheritedRights();
      
       SetRights(oWeb, oItem);
       
       oItem.Update();
     }
   }
});

You get the item and the web from the event properties. But in the delegate you must get a new instance of the web, the list and the item because the outside references are running in the low privileges context. The Method BreakInheritedRights is an extender that calls BreakRoleInhreitance on the item and removes all current RoleAssignments. The not shown method SetRights sets the actual rights to the item. I needed to do this for several lists and the above code was to obscure and hard to understand. So I decided to implement it something like that:

var item = properties.ListItem;
var web = properties.web;

SecurityHelper.RunWithElevatedPrivileges()
        .OnSite(web.Site.Url)
        .OnListItem(item.ParentList.ID, item.ID)
        .Execute(setItemPermissions);

This seemed to be more readable to me. So I was in  the lucky situation that this functionality was enterly new. So I have choosen the easiest way to do it: by creating a set of classes to build up your langauage. So I came up with the following set of classes:

public class SecurityHelper
{
  public static SecurityHelper RunWithElevatedPrivileges() { ... }
  public RunWithElevatedPrivilegesSiteContext OnSite(string url) { ... }
}


public class RunWithElevatedPrivilegesSiteContext
{
  public void Execute(Action<SPWeb> actionToRunElevated) { ... }
  public RunWithElevatedPrivilegesListItemContext OnListItem(Guid listId, int itemId) { ... }
}

public class RunWithElevatedPrivilegesListItemContext
{
  public void Execute(Action<SPWeb, SPListItem> executeOnListItem) { ... }
}

The static RunWithElevatedPrivileges method is the entry point. It allows us by calling the OnSite-Method to create a site context to execute elevated code, modeled throug the class RunWithElevatedPrivilegesSiteContext which gets passed in the site url. Using its Execute-Method we can run elevated code that only needs the web. If you want a list item to be in context, you have to call the OnListItem-Method to get a RunWithElevatedPrivilegesListItemContext instance. This allows you to pass in a callback expecting web and list item. This will be obtained by the Execute-Method in the following way:

public void Execute(Action<SPWeb, SPListItem> executeOnListItem)
{
  SPSecurity.RunWithElevatedPrivileges(delegate()
  {
    using (SPSite site = new SPSite(_siteUrl))
    {
      using (SPWeb web = site.OpenWeb())
      {
        SPList list = web.Lists.GetList(_listId, false);
        SPListItem item = list.Items.GetItemById(_itemId);

        executeOnListItem(web, item);
      }
    }
  });
}

If things get more complex, you shoud prefer to define interfaces that define your language an implement them on your classes or you can use extensions methods like in LINQ.

Have a fluid coding!



Donnerstag, 20. September 2012

BASTA Follow-Up

Für alle die meine Sessions auf der Basta verfolgt haben und besonders für alle die sie nicht verfolgen konnten, hier die jeweiligen Folien und Beispiele.

TFS Express Slides

NoSQL vs. SQL Slides and Examples

Auch die versprochenen kleinen agile Tools die im TFS Express fehlen gibt es zum Download. Dazu einige bekannt Einschränkungen:

  • Funktioniert nur mit der englischen Scrum-Template Version.
  • Alle Operationen laufen synchron - eventuelle Wartezeiten (insb. beim starten) können vorkommen.
  • Die Software wird "as-is" geliefert - Nutzung auf eigene Gefahr.
Wer Fragen dazu hat, kann sich melden.

Viel Spaß damit!

HTTP 503 Error in TFS

The night before my TFS Express talk at the BASTA conference I faced an ugly error with my TFS Express installation. The installation ran fine, I could start management console, access the database but trying to access the website at localhost:8080/tfs yielded the 503 error.

As a result of a quick Google query I found out that there is plenty of discussion on the web about this topic, for example at StackOverflow or on MSDN. Some post state that they never found a solution for this, other show a long list of possible things to try - nothing worked for me.

By luck I found the solution to my problem. I used RavenDb on my machine before, which is running on port 8080 as well. Due to a different problem in Raven I had in mind that it does some urlacl-stuff by reserving an urlacl for the URL http://+:8080. This is used to assign rights for accesing this URL for the logged on user. If you face a 503 error when trying to use RavenDb with IIS deployment you should run the following command line:


netsh http delete urlacl http://+:8080/


It seems that running raven from the console does a urlacl reservation, which in turn makes TFS to stop working. The solution to the problem was similar to the solution mentioned on the RavenDb website. Run the above command line and TFS works fine - I assume RavenDb will no longer work properly.

This is neither a RavenDb mistake nor a TFS mistake - you should just configure these servers to run on different ports if they run concurrently.

Anyway this is one possible solutions out of a thousand and perhaps it might save someone some valuable time. Happy serving...




Sonntag, 16. September 2012

Creating a child task for a backlog item with TFS API

Because TFS Express lacks the agile planning tools of the full version, I was writing a small tool that makes creating tasks as children of a backlog item more enjoyable. It took me a while to figure it out, so I share my result.

First you need a reference to the team project collection:

var tfs = new TfsTeamProjectCollection(new Uri("https://your.tfspreview.com"));
tfs.EnsureAuthenticated();

var workItemStore = tfs.GetService<WorkItemStore>();

The the new task work item must be created. To instanciate a work item you must pass its type. You get this from the Project class.

var project = workItemStore.Projects["NameOfYourTeamProject"];
var taskType = project.WorkItemTypes["Task"];
var task = new WorkItem(taskType);
task.Title = "A new task"; 
task.State = "To Do";      
task.Save();

Next, we need to create a parent / child link. We need a WorkItemLinkTypeEnd instance that we can get from the WorkItemLinkType that we can get from the work item store like this:

var linkType = workItemStore.WorkItemLinkTypes["System.LinkTypes.Hierarchy"];
var taskLink = new WorkItemLink(linkType.ReverseEnd, task.Id);

The taskLink instance is a parent / child work item link whose reverse end (where it points to aka the child) points to the id of the task work item we created formerly. To connect the close end to the parent, the backlog item, we have to load it and put the link into its Links collection:

var backlogItem = workItemStore.GetWorkItem(backlogItemId);´
backlogItem.Links.Add(taskLink);
backlogItem.Save();

Thats it - the new task appears as a child of the backlog item (for example in the taskboard). Hope this may save someone some time :-)