Announcing the IndigoWonks Mailing List

I had a bit of a brainwave this afternoon and decided to get an Indigo-specific mailing list going. You can subscribe to it by clicking on this link and clicking Send in your e-mail client.

The idea behind the list is to have a place where people who really want to know Indigo inside out can hang out, post questions and hopefully get good answers back from others who are also using the technology.

It would be great if we could get some of the folks from the Indigo team on the mailing list – but they must be pretty busy at the moment.

Michael Still was kind enough to set up a mailing list archive over on his site like he has for a number of the mailing lists based here in Australia (although like all the mailing lists this one is open to the world).

Indigo Ascend Training – Day Three

I’ve already documented my experiences from day one and day two of the Indigo Ascend training that I went to in Sydney last week. This will be my final post where I talk about the training specifically, future posts about Indigo will zoom in on particular aspects of the technology.

On the third day we looked at some of the extensibility points of Indigo and learned about some of the internal mechanims that glue all those extensibility points together. I was hoping to include some code samples in this post that I had written but I’m still struggling grasping all things that I need to implement to get my own custom binding and transport up and running – but if I did that then this post may not arrive until the end of the week!

Fortunately the folks on the Indigo team has done the job for me and created a sample transport and associated binding for UDP. If you have the WinFX SDK installed you can grab it from the following directory:

As you can see the implementation is quite hairy, but I think I have a pretty good conceptual understanding of how it all hangs together.

First up there is a listener listening for incoming connections (I’ve just talking about the service-side here) – and, while the service is running there is a continuous loop running where the listener is asked for a channel.

A channel represents a logical connection and processing pipeline for a message coming into the system, it handles doing things like decoding the message from its underlying transport format and giving it a logical message-orientated representation.

Messages are finally handled by service code when the dispatcher receives the message off the end of the channels and converts it to a call to a method marked with an operation contract. I like to think of it as a pump sucking goop up a straw

Anyway – I hope to actually grok most of this stuff this week and keep posting about it – distributed comms is so intresting.