Sometimes you just have to be grateful for your friends.

I was intending to go into work this weekend to set up the two servers I need for my project. Actually, I was intending to go in and do as much as I could to set them up; but I knew I wouldn't get it all done. There's just too much I don't know - like the IP address of the proxy server and the password for it. I am a programmer after all and not a sysadmin.

Craig, on the other hand is a sysadmin. I spoke to him this lunch time to try to pick his brains about a few things, to try to ensure I at least made some progress when I came in. We talked for a while, and he told me how to get IP addresses allocated, and wrote down some stuff about gateway addresses and such, before I had to leave for a meeting.

When I popped back in to see him at four o'clock this afternoon to confirm a couple of things, he said, "Oh! I've just started them off. There didn't seem any point in your coming in this weekend when I could get it done in an hour or two."

By the time we left at four-thirty, the XP box was set up and the Linux box was busily updating itself with all the patches published since I bought the discs, some months ago. When we get back in on Monday there should be very little left to do.

What a pal. I think that's earned him a bottle of wine this Christmas.

The fact we both speak Welsh probably didn't hurt matters, either.

The weather.

Yes, even Cardiff is cold today and that's pretty unusual. Still, it does mean that the temptations to do all the other things that are currently looking more interesting than working on my dissertation are that bit less powerful than they were. Heck! Even ironing shirts is looking more attractive at the moment.

The project specification has been submitted and it's pretty much what I had before. My dissertation adviser said she was happy with it, so I didn't argue. I just submitted it. So that's some percentage of 10% of the final mark now in the bag.

The next step is to submit a project design, for another 10% of the total marks. As far as I can tell from the guidelines that pretty much means the software specification in the case of my project. Which is fine, except that they want the thing on 4 pages of A4 or 12 - 15 Powerpoint slides. My experience from work is that software designs run to tens if not hundreds of pages. How I'm going to stick to the limits they set here, I've no idea.

But sitting around worrying about it won't help. I'll just have to do what I can. And quickly.

Just shows what a family drama and a heavy cold can do to your schedule.

Still, I have got some feedback from my supervisor on the project specification that I've been working on: and it's positive. That's quite a relief, because I wasn't too sure about it myself. With any luck then, I'll finish the specification off tomorrow and then I can get on with the design.

I had hoped to install my servers last weekend, but what with one thing and another... And it's probably best for me to concentrate on the spec this weekend. I'm not enjoying writing it, so best to get it out of the way.

With any luck, I should be able to install the servers next weekend. That's the plan anyway.

Right. Back to the steam, the Night Nurse, and an early night.

I've been away at a conference for a couple of days, so the blog's not been updated as much as it should. There is some news, though, and it's all pretty good.

Firstly, I've now got the two computers I needed. Temporarily, I've stashed them away in our office with the legend, "Peter's research machines. Don't even breathe on them" plastered all over them in thick, black felt tip pen. They're still there as of 17:00 today, so it must be working.

I've also found out two more things about .NET and Mono. Getting a Linux/Unix daemon to start at boot time was one of the problems I had to solve; and thanks to help from Robert Jordan, who supplied a script, I've managed to get this working. The script is SuSE Linux specific, but should be easy enough to change for other distributions.

The other thing I've found out is that you can use configuration files with remote proxies instantiated from interfaces. The app.config file is a bit different and you can't use the new keyword to instantiate the proxy, but it does work - and may be better in many circumstances. I'm indebted once more to Robert for this.

I've written up what I know about remoting in two documents: one for metadata proxies and one for interface-based proxies and asked for comments from the people on the Mono mailing list who'd expressed interest. If they don't come back with comments or questions by the end of the week, I'll submit the documents to the Mono project.

My dissertation advisor reminded me that I have to have the project specification ready by the end of the month, so I did a lot of work on that this weekend and submitted what I have so far to my advisor for comments. When I've had the comments I'll try to press on and finish it this Sunday - all being well.

Before that, on Saturday, I'll try to set up my test machines with all the necessary software. That should keep me busy.

One of the things you need to do in order to expose remote objects on an application server is to provide a host for the object. The host listens for communications on a specified port and then creates the object that the client specifies in the communication. In .NET this is done via a URI, which is a generalisation of the kind of string you type into a web browser to find a particular web page:

<protocol>://path/to/the/resource

For a web page, the protocol is http, usually, but for remoting it can be other things like tcp (transport control protocol). But I digress.

If you want to, you can use an ordinary program that you start manually as the host for the remote object, but this has a number of drawbacks. Firstly and most obviously, you have to start it manually. Secondly and not quite so obviously, you have to be logged in in order to start the program. Furthermore, the program is likely running in the foreground (e.g. in a terminal window), so it could accidentally be terminated.

What we would really like is to host the object in a program that starts automatically when the server boots and continues to run in the background without any user intervention. This type of program is called a "Service" in Windows, or a "Daemon" in the Unix/Linux world.

The Windows version of .NET provides a lot of help to allow you to host your remote object in a Windows service - including Installer objects that you can include in assemblies containing class(es) derived from ServiceProcess.ServiceBase, and which can be used by a .NET tool called installutil to install the Windows service.

The Mono team have managed to transfer much of this to a Unix/Linux environment: but the process is a little different. You have to use a tool called mono-service whose usage is not immediately obvious - to me at any rate.

Thankfully Robert Jordan and Jörg Rosenkranz from the Mono mailing list provided me with enough help and advice to see me through. Robert, in particular, provided me with a script that installs the service by calling mono-service with the required parameters.

I had a lot of trouble getting it to work even then, until Jörg suggested i check /var/log/messages to see what was being output (Doh!). It gave a perfectly clear message telling me that I had an element attribute mis-configured in my app.config file. Windows requires:

<customErrors mode="Off">

Mono required:

<customErrors mode="off">

Spot the difference? It's the difference between a small and a capital 'O'.

Robert has now made Mono case insensitive, but my installation has not yet been updated with his patch.

I'm still not done, though. The above means I can start the daemon process in the background such that it will persist even if I log off. At the moment there is nothing to make it start when the machine is switched on. I've asked for advice and expect this will not be a problem. I don't think so, anyway.

You know, there's always the temptation to think you know more than you do. You work away at your job and you find solutions to problems and you think you've learnt all there is to know.

Then you meet someone who knows more than you do. Comes as a shock.

I've spent a good part of today "talking" to the people on the mono-list mailing list, about .NET remoting. In particular we've been discussing the ins and outs of hosting remote objects in services (Windows) or daemons (Unix/Linux). Now, these are the people - some of them, at least - who've coded the Mono implementation of .NET. The breadth of their knowledge is breathtaking.

What's more, when you look at what they've achieved with the Mono project, you just have to forget your pride and satisfy yourself with "sitting at the feet" for a while. I'm full of admiration for what the Mono team has achieved.

So plaudits and kudos to the Mono team. Absolutely amazing.