Running my .Net Core mDNS service on Windows IoT

As part of my ongoing experiments with C# and mDNS (to build my own Homekit accessory), I got to the point where I wanted to run my code on a Raspberry Pi.

Microsoft have released a version of Windows 10 that will run on a Raspberry Pi in a headless mode. The main advantage of this is that it contains the .Net Core runtime!

To get started, download Microsoft IoT manage and fire it up. Under the menu, you’ll see an option to Set up a new device. This lets you flash an SD card with the code necessary.

iot flashing UI.PNG

iot flashing.PNG

Once the formatting and flashing is complete, you’ll have an SD card containing Windows IoT. Pop this into your Raspberry PI, and after a minute or five it will appear under the My devices view.

To get me started, I launched Remote Powershell. When it started, I got prompted for credentials.

iot powershell ip.PNG

This includes the IP Address and the account Administrator (the password for which, you set earlier). I found that this just didn’t work. I replaced the IP address with the machine name (minwinpc) and it worked!

iot powershell ip domain.PNG

I just realised this is a real Windows XP dialog!

After Powershell started, I opened a file share and created a directory called Climenole. To get my little Console app ready, I needed to compile it for ARM. Thankfully, this was straightforward. From the command prompted, I ran this command

dotnet publish -r win-arm

This compiles the app for the win-arm architecture. From the project directory, you can access

\bin\Debug\netcoreapp2.0\win-arm

to see all the published files. I took all these files and copied them across to the Climenol directory I created on the Raspberry Pi.

Once the copy completed, I could run my app using Powershell.

iot wrong ip address.PNG

It didn’t work the first time as the hardcoded IP address wasn’t right, but after a tweak,

iot responding to packets.PNG

It started answering responses and even appeared in Homekit.

img_48941.png

A good first step and proved that my mDNS was portable.

Next challenge is getting all the crypto code working, so that I can actually add and control the accessory from Homekit. It was a pain to get it working on the .Net Framework, so I suspect it will be no picnic on Core!

Update (07 Jan, 2019) I’ve had a couple of people ask to see the mDNS code. It’s up on Github – https://github.com/tomasmcguinness/dotnet-mdns

Advertisements

Apple Bonjour for .Net Core

As part of my work on building a .Net implementation of Apple Homekit protocol, I want to have it run on a Raspberry Pi. My plan is to accomplish this using Windows 10 for IoT. This is basically a cut down version of Windows 10, designed to run .Net Core and UWP apps. I haven’t really explored it very much, but it seems to suit my needs. I can deploy my Homekit service and put the Raspberry Pi in the cupboard.

The first piece of functionality I need for my Homekit implementation is the broadcasting of the accessories using Bonjour. Bonjour is apple’s zero configuration protocol implementation. It is available on Windows, via Apple’s SDK, but unfortunately, it’s a COM component, so running it on Raspberry Pi is a non-starter. I searched around on the internet for a few hours and discovered, to my immense disappointment, that there are no Nuget packages for advertising services over Bonjour. Lots of ones for browsing and searching, but none for advertising.

These kind of situations, whilst annoying, do provide an opportunity to learn something new. What would it take to create a simple implementation of Bonjour that would run on .Net Core, on a Raspberry Pi. Let’s find out 🙂

To get the ball rolling, I created a .Net Core console application in Visual Studio. This doesn’t achieve anything in and of itself, but makes me feel like I’m making progress 🙂

A read through a few articles on Bonjour;

and I was ready to start. General searching around the web, led me to RFC-6762 (https://tools.ietf.org/html/rfc6762), which describes Multicast DNS or mDNS. This is used by Bonjour. I do love a good RFC.

After reading the first few pages, I established the following facts; mDNS, in essence, works by resolving .local addresses e.g. computer.local or hap.local. It does this by sending requests over multicast to the group 224.0.0.251 on the port 5353. I had come across the multicast technology (my router didn’t support it) a few years ago, so I was familiar with the main concepts.

Converting this into code, I came up with

public void Start()
{
 try
 {
 UdpClient udpClient = new UdpClient();

udpClient.ExclusiveAddressUse = false;
 IPEndPoint localEndpoint = new IPEndPoint(IPAddress.Any, 5353);

udpClient.Client.SetSocketOption(SocketOptionLevel.Socket, SocketOptionName.ReuseAddress, true);
 udpClient.ExclusiveAddressUse = false;

udpClient.Client.Bind(localEndpoint);

IPAddress multicastaddress = IPAddress.Parse("224.0.0.251");
 udpClient.JoinMulticastGroup(multicastaddress);

while (true)
 {
 Byte[] data = udpClient.Receive(ref localEndpoint);
 string dataAsString = Encoding.UTF8.GetString(data);
 Console.WriteLine(dataAsString);
 }
 }
 catch (Exception exp)
 {
 Console.WriteLine(exp.Message);
 }
 }

This code essentially listens on port 5353 for broadcasts to the group 224.0.0.251.

When I fire up the console app, I just see this

Console

Not much to see. In order to generate some Bonjour traffic, I use an app called Bonjour Browser

I launch this and again, I don’t see much:

Bonjour

However, a few lines appear in my console app:

Console with data

Right now I don’t have a clue what these are, but I can see what might be dns requests.

More detail to follow!

 

Developing a game for both iPhone and Windows Phone 7

Since completing my first iPhone app and having it published on the AppStore, I’ve been held by the idea that I should write an app for the Windows Phone 7. Since this is a small market at the moment, it’s an ideal time as getting noticed is more likely.

With this in mind, I’ve decided to write a small game. One that might make me some cold hard currency. I came up with an idea for the game whilst out for run. It’s pretty simple and whilst it won’t win me any awards, it should be simple enough to write. To makes things even more interesting, I’m going to write the game for both the Windows Phone 7 XNA platform and the iOS platform. I should be able to write the code in parts, making sure each platform functions correctly as I go. Phew.

Platform Differences

These two platforms have significant differences, but some similarities too. Aside from the obvious ones, like manufacturer, the differences are mainly superficial. Both have a very narrow hardware range. The iPhone has only four models and their specs are predictable. The WP7 has many more models, but they base specification for all these devices is the same. This makes the experience predictible on both platforms. Since the iPhone has been around much longer, older models of the hardware get taken out of the equation.

Development Differences

When it comes to developing on these platforms there are some differences too. Thankfully, writing code is writing code, so once the basic components of an application are understood, the differences are really down to IDE, API and programming language. Whilst developing Caffeine Club, I’ve become quite adept at switching from Objective-C to C# so this won’t worry me too much.

iOS Development

Development on iOS is done, as mentioned, in Objective-C and C++. For the purposes of game development, the Framework of choice is Cocos2d. This is an external framework as there are no dedicated game related frameworks in the iOS SDK. The recently launched Xcode 4 is Apple’s IDE and whilst it’s very powerful, I’ve yet to see it match Microsoft’s offering. I think I need more keyboard shortcuts 😉

For physics, the Cocos2d framework comes bundled with two physics engines – Box2D and Chipmunk. The former is a C++ library and if offers some very powerful simulation features. Chipmunk is an Objective-C library and whilst very comprehensive, it’s not as powerful as Box2D. Whilst the C++ syntax can be a little scary, I’m going to go with Box2D.

Windows Phone 7 Development

Unlike iOS, WP7’s SDK includes a technology called XNA. This framework is the game development platform for both the XBox 360 and the Windows Phone 7. It can also be used on any .Net platform. It’s effectively a framework designed and build for the purpose of writing games. This makes it easier to get your game “off the ground” as it were. Visual Studio 2010 is the IDE I will be using. C# is the language of choice too.

In terms of Physics engines for WP7, the Farseer Framework is what I will be using. This is a very robust engine and offers a very easy programming model.

Common Bits

I’m going to try a tool called Tiled for developing my levels. This is a tile based level generator, that is compatible with both Box2D and Farseer (the former I’ve tested, the latter I haven’t). This will mean that any levels I build, should be compatible with both platforms.

As for audio, I’m clueless. I’d imagine this will be MP3, but I’ll figure that out at the end. Cocos2d does include an Audio specific framework and XNA also has an API for audio, so it shouldn’t be too difficult. Well, less difficult that getting the sounds in the first place!

Source Control

For this I’m going to use Git. I would have preferred to use Perforce, but XCode 4 has dropped native support for Perforce and added native support for Git. I need to get an add-in for Visual Studio 2010, but I’m sure there is a compatible one.

I’ll be hosting my source code in the “cloud” somewhere. I’m testing some vendors at the moment to ensure it all works.

Wish me luck

Finally, please wish me luck. This is a totally bonkers I’m committing to, but it will be one hell-of-a learning experience if nothing else. I’m still trying to figure out how to structure my posts and whether I’ll alternate between iOS and WP7 or whether I’ll post the code side-by-side. I’ll do a few posts and find out.

Hopefully, somebody will find this informative.