Share
nvents

.NET events across the network

nvents 0.7 with poco and IPC support

Removing IEvent requirement (breaking change)

The IEvent interface has been removed and you can now publish and subscribe to any poco class.

using System;
using Nvents;

namespace NventsSample
{
  class Program
  {
    static void Main(string[] args)
    {
      // subscribe to events
      Events.Subscribe<FooEvent>(
        e => Console.WriteLine(e.Bar));
      // publish events
      Events.Publish(new FooEvent { Bar = "FooBar" });
      Console.ReadLine();
    }
  }
  
  public class FooEvent // no longer inheriting from IEvent
  {
    public string Bar { get; set; }
  }
}

IPC (inter-process communication) support

Communication on the same machine (without the need for a TCP connection) is now supported via named pipes.

using System;
using Nvents;
using Nvents.Services;

namespace NventsSample
{
  class Program
  {
    static void Main(string[] args)
    {
      Events.Service = new NamedPipesService(); // can also name the pipe; new NamedPipesService(pipe: "pipe name")
      
      Events.Subscribe<FooEvent>(
        e => Console.WriteLine(e.Bar));
      Events.Publish(new FooEvent { Bar = "FooBar" });
      Console.ReadLine();
    }
  }
  
  public class FooEvent
  {
    public string Bar { get; set; }
  }
}

Another breaking change is that InProcessService has been renamed to InMemoryService.

Tags:

nvents 0.6 now runs on .NET 3.5 and 4.0

Why was there no support for .NET 3.5 prior to nvents 0.6?

To enable automatic discovery of all nvents clients we are using WCF Discovery which is a implementation of WS-Discovery.

However, WCF Discovery is only supported by .NET 4.0 so nvents could only run on that framework.

What was required for .NET Framework 3.5 support?

We could have used a custom implementation of WS-Discovery that works on .NET 3.5, but decided to create a simpler solution based on Client/Server Rendezvous on the LAN.

One implication of this is that nvents for .NET 3.5 is not compatible with nvents for .NET 4.0

I haven't tested it but I do believe that the usage of NetDataContractSerializer already disables .NET 3.5 to .NET 4.0 serialization.

Version 0.5 was a bug fixing release

A WCF Timeout Exception issue was reported in version 0.4 and a fix was released within a couple of days.

EventSubscription<TEvent> was added to use standard events

using System; using Nvents; namespace NventsEventSubscriptionSample { class Program { static void Main(string[] args) { var fooEvents = new EventSubscription<FooEvent>(); fooEvents.Published += (s, e) => Console.WriteLine(e.Event.Bar); Events.Publish(new FooEvent { Bar = "FooBar" }); Console.ReadLine(); } } public class FooEvent : IEvent { public string Bar { get; set; } } }

Download the latest version or view the nvents page.

Performance improvements and inheritance support in nvents 0.4

How nvents handles subscribers

Prior to version 0.4 nvents searched for subscribers and opened the connection to each server on every publish.

Nvents 0.4 keeps the connections open and sends the publish event to known subscribers before searching for more subscribers. This, of course, dramatically increases the performance.

Automatic support for inheritance

using System; using Nvents; namespace NventsInheritanceSample { class Program { static void Main(string[] args) { Events.Subscribe<ICustomerEvent>( e => Console.WriteLine("Something happend with customer {0}", e.CustomerId)); Events.Subscribe<CustomerAddedEvent>( e => Console.WriteLine("Customer {0} was added", e.CustomerId)); Events.Subscribe<CustomerChangedEvent>( e => Console.WriteLine("Customer {0} changed", e.CustomerId)); Events.Subscribe<CustomerNameChangedEvent>( e => Console.WriteLine("Customer {0} changed name from {1} to {2}", e.CustomerId, e.OldName, e.NewName)); Events.Publish(new CustomerNameChangedEvent { CustomerId = 1, OldName = "Old Name", NewName = "New Name" }); Events.Publish(new CustomerAddedEvent { CustomerId = 2 }); Console.ReadLine(); } } public interface ICustomerEvent : IEvent { int CustomerId { get; set; } } public class CustomerAddedEvent : ICustomerEvent { public int CustomerId { get; set; } } public class CustomerChangedEvent : ICustomerEvent { public int CustomerId { get; set; } } public class CustomerNameChangedEvent : CustomerChangedEvent { public string OldName { get; set; } public string NewName { get; set; } } }

Will output the following statements

Something happend with customer 1
Customer 1 changed
Something happend with customer 2
Customer 1 changed name from Old Name to New Name
Customer 2 was added

Tags:

Encryption, handlers and filters in version 0.3

Some background on encryption in WCF

The NetTcpBinding (used in nvents) in WCF supports both Transport- and Message-level security. It’s highly recommended to use this functionality when you need to secure a WCF service.

However to enable one of these you need to use Windows authentication or a certificate. See more information in patterns & practices Improving Web Services Security (Chapter 7 - Message and Transport Security).

Encryption in nvents

Windows authentication and certificates does not fit well with the goal of nvents (being simple in it’s nature). We should only need to set the encryption key string and be done with it.

Events.Service = new AutoNetworkService("encryption-key");

Why isn’t the encryption key just a static property on Events?

  • We would like to keep the Events members to a minimum
  • Not all services supports encryption (it makes no sense for the InProcessService to support encryption)
  • We can create and consummate multiple nvents services in the same application, some of these might require encryption when others don’t

How is the encryption applied?

A custom serializer that’s using NetDataContractSerializer under the hood for the serialization. Before the serialized event are written there is a check if encryption should be applied and the bytes are encrypted using .NET AES implementation with the specified encryption key, likewise the data is decrypted before deserialization occurs.

Note that if a malicious user get a hold of your encryption key (by decompiling your assemblies) and has the ability to monitor your network your data may still be compromised.

Event handlers

In addition to subscribing directly to events it’s now possible to register event handlers to separate event handling further.

using System; using Nvents; namespace NventsHandlerSample { class Program { static void Main(string[] args) { var handler = new MyEventHandler(); Events.RegisterHandler(handler); Events.Publish(new MyEvent { Bar = "FooBar" }); Console.ReadLine(); } } public class MyEvent : IEvent { public string Bar { get; set; } } public class MyEventHandler : IHandler<MyEvent> { public void Handle(MyEvent @event) { Console.WriteLine(@event.Bar); } } }

Filters

Filters is a simple way to only subscribe to events that meets some specific demands.

using System; using Nvents; namespace NventsFilterSample { class Program { static void Main(string[] args) { Events.Subscribe<FooEvent>( e => Console.WriteLine("Unfiltered: " + e.Bar)); Events.Subscribe<FooEvent>( e => Console.WriteLine("Filtered: " + e.Bar), e => e.Bar.Contains("Foo")); Events.Publish(new FooEvent { Bar = "FooBar" }); Events.Publish(new FooEvent { Bar = "JustBar" }); Console.ReadLine(); } } public class FooEvent : IEvent { public string Bar { get; set; } } }

Download the latest version or view the nvents page.

Fork me on GitHub