Monday, April 30, 2007

Picture Messages in SMS - Another Update

I've created a (very crude) bitmap editor so I can make a 72x28 pixel OTA bitmap. It flickers like crazy when you're editing, but it gives me enough functionality to prove that Esendex's SendWDPService can be used to send SMS picture messages.

I drew a square in my editor and sent the message with some custom text. I've noticed that the £ (sterling) sign came through as a $ (dollar), so there's some encoding problem there, but mainly I'm happy with what I've got.

Now I need to package up this solution so it can actually be used somewhere. I'll probably write a Codeproject article on it when I finally get around to making it work simply.

Thursday, April 26, 2007

Picture Messages in SMS - Update

Found a couple of hours to check out SMS Picture Messaging last night. Using the example on the Nokia sample I can send the example picture with some text. I haven't yet managed to send my own picture, as I need to figure out how to encode the OTA bitmap.

I was thinking of creating my own editor to create the bitmap in the format that I need, but I reckon there must be ones already out there that I can use. If not I think I'll look into converting a standard monochrome bitmap to OTA format. Then I can use something like MS Paint to create the picture.

So at the moment I can sort of send a picture message. I can specify the text that I want to include anyway, and just use the "canned" picture that Nokia supply as an example. The text seems to encode properly, but I need to look into what encoding I need to be using for this to work completely.

As an experiment though I did all of this without touching Esendex's core messaging system. I sent the message through our SendWDPService Web Service that we originally implemented to allow people to send OTAP settings. The method simply takes originator and destination ports, and then some content which can be split across multiple PDUs.

The work outstanding is to figure out a way of easily encoding a picture for inclusion in the message. When that is done I'll write a more detailed explanation of how to send a Picture SMS.

Friday, April 20, 2007

AdoNetAppender in log4net

I've been running tests recently that required a quite detailed look into log files that log4net generates as part of our logging framework. Currently we have a number of Appenders loaded, such as RollingFileAppender, to log to different places.

However, a text file isn't always that easy to search through. Finding 1 separate entry is fine, but you can't list all of the error logs you have in the file, and you can't just show all messages that contain a particular string or string pattern. You could do this if these log entries were in a database table.

So as a little test I loaded in an AdoNetAppender after setting up a test database table to log to. I just used the config example as a base, and started logging.

That was all I really needed to do, I was impressed with how easy it was. It simplified the searches that I needed to do no end, and it would be a pretty easy task to tack an ASP.Net front end onto it to work as a log reader.

The Appender is very flexible, only taking a SQL statement to execute and a number of parameters to pass into it. The example config entry gives you pretty much everything you need, except maybe the machine name where the log entry came from.

If you do need this then it is relatively easy to add, due to the Appender's flexibility. Just add a column to the database (I've called it MachineName), and change the SQL statement to pass in a @machineName parameter.

Then in the parameters list, put something like this:

<parameter>
  <parameterName value="@machineName" />
  <dbType value="String" />
  <size value="50" />
  <layout type="log4net.Layout.PatternLayout">
      <conversionPattern
            value="%property{log4net:HostName}" />
  </layout>
</parameter>


That's all you need to log the machine name where the log originated.

Tuesday, April 17, 2007

Setting SoapExtensions Programmatically

Creating a class that inherits from SoapExtension can provide (among other things) an easy way of logging XML that is passed between a client and server during Web Service calls. To apply your SoapExtension to an entire Web Service, then you can make changes in the Web.config file.

Likewise, if you are running a client application then you can add a section to your app.Config file.

However, if you are connecting to a Web Service from a class library then how do you get your logging?

I've just had this problem. We have code running as a COM+ server, so we can't add the setting to the app.Config file. I suppose if we wanted to we could add it to the dllhost.exe.config file, or mess around with the Application Root Directory, but for a number of reasons these aren't really an option.

But we can set SoapExtensions programmatically in our code:

  1. Create the SoapExtension class you want to use
  2. Create a SoapExtensionAttribute class, overriding the ExtensionType property
  3. Apply the attribute to the method.
Check out this blog for full code samples

Monday, April 16, 2007

Tech Ed 2007 - Orlando, FL

Esendex are sending me to Orlando, FL this coming June for Microsoft's Tech Ed 2007. I've known about it for a while, but now the conference is paid for, my flights are booked, my hotel room is reserved, and my new machine readable British passport has been delivered.

It'll be the first time I've been to one of these conferences, so I'm not entirely sure what to expect. Neither have I flown on my own, or for so far before. But I'm looking forward to it all the same.

I have no idea yet what I'm going to do when I'm over there, but hopefully that should be planned a little closer to the time.

Thursday, April 12, 2007

Load balancing MSMQ - Overview

Didn't realise my previous MSMQ post was so long. If you haven't got time to read it all, then here are the main bits:

See my previous post for more detail.

Load balancing MSMQ

I've been investigating how to set up MSMQ in a load balanced environment using Microsoft's Network Load Balancing, so that messages are distributed over a number of servers without the hassle of having to reference each server individually.

In theory it’s relatively easy, and in practice it’s not too difficult once you’ve got past a few teething troubles.

First make sure the queues are named the same way on each server that you want to put in the cluster. For testing you can use virtual servers, but there are a few restrictions to be aware of.

Add each server to the cluster, and make sure you forward port 1801. You can set the Affinity to None, as a message should be able to be queued on any server, so a session doesn't need to be maintained.

When referencing the queue from code, use Direct Format TCP names (i.e. FormatName:DIRECT=TCP:192.168.x.x\queuename). You can use the OS format, but you need to add a registry key for it to work properly. KB article 899611 tells you how to do this if you need it.

Now you should be in a position to send a message to the cluster, and have it delivered to one of the queues. In basic terms this is all that is required. At this point the load balancing works, so if that works for you then fine.

However, if you have a system where many messages are being pushed around, then you'll soon notice a few flaws with this. When you send to a remote queue what actually happens is that the message goes into the client machine's Outgoing Queues. The MSMQ service is then responsible for connecting to the remote server and pushing the messages to it.

What this means in practice is that when you send a message, MSMQ opens a connection to the cluster. NLB assigns this connection to one server, and the messages are pushed through. If you stop this server in the cluster (for maintenance, for example), then the connection between client and server is ended.

You'll see messages piling up in the Outgoing Queues on the client machine. By default MSMQ reconnects after 60 seconds, but in practice I've seen that this is usually about 70 seconds. After it reconnects, the messages will go onto another server.

If you require more performance than this, then I'm sure you'll agree that 60-70 seconds is too long to wait for MSMQ to realise it needs to make another connection. Luckily there is a WaitTime registry setting you can make that reduces this time. However, the additional 10 seconds seems to remain on top of what you enter here.

Once this is sorted out you're still left with a problem. Lets say we have 2 client machines sending messages to a cluster that has 2 servers in it, with client 1 connected to server 1, and client 2 connected to server 2. If we take down server 2, then client 2 reconnects to server 1, and everyone is happy.

When we bring server 2 back though, as the connections are already established from clients 1 and 2 to server 1, server 2 won't get any messages.

This is because by default MSMQ keeps an idle connection open for 5 minutes. If you are running a high performance system, then its likely that there will be no time for which a connection will be idle for this time. This is where the CleanupInterval registry key comes in. This tells MSMQ how long to leave an idle connection open.

Reduce this to a suitable time for your system. This is likely to give you a much more balanced distribution of messages across the servers in you cluster.

And there you have it. Not too difficult once you've found the pieces of information you need.

Wednesday, April 11, 2007

Reflector for .Net

I might be one of the last people to find this, but if you ever have the need to look at the code in the System .Net assemblies, then go and get Reflector for .Net by Lutz Roeder.

Basically select a method that you want to look at and the code is displayed for you.

Very useful app if you want to know what's happening under the hood in the framework.

Tuesday, April 10, 2007

Durgaprasad Gorti's WebLog : Using System.Net Tracing

If you've ever used something like Ethereal to trace network traffic you'll know that it can be confusing, especially if you're sending lots of packets to different destinations.

I've been enlightened by a new .Net 2 feature that causes the System.Net classes to log what it's doing, and you can do it without making any code changes.

Check out this blog for details: Durgaprasad Gorti's WebLog : Using System.Net Tracing

Haven't given it a go yet, but it looks like something we can make use of to log what the framework is doing.

Monday, April 02, 2007

Ajax Vulnerabilities

Interesting article over at CBR Online about a vulnerability found in pretty much every Ajax toolkit out there when using the JavaScript data format JSON instead of XML as the transport.

Slashdot's picked up on it as well, and the resulting discussion deserves a good read through too.

Essential reading for those developers using this new technology.