September 2006 - Posts
Sometimes in the course of troubleshooting some gnarly protocol problem, a gem of humour will appear that normally would go unwitnessed. I've had two such occasions recently and wanted to share these with the world. So here are my two nominations for "Funniest things said by one computer to another":
- When doing a WiFi survey (war driving) recently, I spotted this SSID:
"Jeffs WIFI neighbours f*** off" (censorship mine).
- Spotted in my SMTP server logs (remember, this is all machine generated…):
EHLO - tigranetworks.co.uk 0 4 0 500 -
500+Bloody+Amateur!+Proper+forging+of+mail+requires+recognizable+SMTP+commands!
HELO - tigranetworks.co.uk 0 4 0 735 -
250+Ok 0 6 0 21594 -
RCPT - TO:<xxx@terra.com.br> 0 4 0 21594 -
250+cmpsolv.com+Is+thrilled+beyond+bladder+control+to+meet+tigranetworks.co.uk 0 78 0 1063 -
MAIL - FROM:<xxx@xxx.net>+SIZE=3945 0 4 0 22625 -
250+Ok 0 6 0 22406 -
DATA - - 0 4 0 22406 –
Who says computers have no sense of humour? If you have a similar example, why not post a comment, or blog it yourself and track back to this article.
Just thought this was an interesting statistic. IE7 is already responsible for 8% of the traffic hitting my web servers.
This is a pet subject of mine. Having worked in the telecommunications industry for almost 20 years, I've come to the conclusion that for the most part, Britons don't understand how telephone numbers work or how to write them down. Oftel have to take the blame for this as they've consistently messed about and renumbered everything since the seventies and given out confusing messages about how to write telephone numbers while failing to explain what any of it means. People in Cardiff used to be (01222) but now they don't know if they are (029) or (02920). Most people write an international format with the first zero of the area code in brackets, which is meaningless to everyone. How much do you pay for an 0845 number versus an 0860 number? How much does that 0900 number cost? Is 0500 free or premium rate? Compare this confusing state to the system in America, where everyone, all 350 million of them, enjoy the consistency of the 10-digit format known as the North American Numbering Plan. Everyone knows what type of number they are dialling and how much it will cost. No-one needs to write long distance prefixes or country codes in mangled formats because everyone understands exactly what all the digits mean and how to dial them. An American phone number looks like this, always:
(123) 456-7890
Simple. For us callers 'across the pond' we just prefix the country code:
+1 (123) 456-7890
What could be simpler than that? The latter format is what Microsoft calls "Canonical form" in the Telephony API (TAPI) and it contains the country code, an area code in brackets devoid of any dialling prefixes and the subscriber number. It might not be immediately clear why, but when entering phone numbers into a computer, that's the format you should use. You'll be tempted to omit the country code and put the leading zero in, because that's how we've been told to write phone numbers, but that 0 is redundant and should be left out. Why? To ensure that those numbers will be understood anywhere in the world by any telephone device or any person. Let's look at an example.
Let's say we enter a number in Outlook in the usual UK notation: (01443) 208678. We go on a road trip, buy a modem and want to dial into the office computer. We fire up our communications package and everything works.
At our remote office, there is a PBX that needs a '9' to get an outside line. Simple, configure the dialling options to add the 9 for us. It still works.
Now we take a trip on Eurostar to Paris. We dial into the office computer but alas! Nothing works now. The computer no longer understands our numbers. What country did we want to dial? There's a leading zero in all of our numbers that is meaningless abroad and needs to be left out, but there's no way to configure the dialling options to do that.
Oh well, we can live with not phoning home from Paris. We can use Skype! We install the latest Skype toolbar for outlook, but alas! Skype expects those pesky canonical numbers, too!
As the global village becomes ever smaller and as VOIP systems become ubiquitous, this will become more important, so get into the good habit now. Whenever you enter a phone number into an electronic device, be it a mobile phone, smart phone, PDA or Outlook; always enter your phone numbers in canonical format:
+country (area) subscriber-number.
+44 (1443) 208678
Don't put the leading zero on the area code. Americans know that is the long distance prefix and so does your computer. It will be automatically added (if needed) when the number is dialled. When you travel, you simply tell the computer what country and area code you are in and it will be able to work out exactly what to dial for every number in your address book, anywhere in the world.
The block_vml.vbs script that is available from http://isatools.org/block_vml.vbs, documented by Microsoft and discussed on EBitz has a bug that means it doesn't run correctly on SBS servers. At least, on my server (running SBS 2003 R2 with ISA 2004 build 4.0.2163.213) the script chokes on one of the RWW rules:
-- Examining rule 'SBS RWW Inbound Access Rule'...
U:\Packages\Downloads\block_vml.vbs(384, 2) Microsoft VBScript runtime error: Object doesn't support this property or method: 'oFpcR
ef.Scope'
If the scipt works correctly, you will see a dialog box confirming that the script has completed. If you do not see the dialog box and your script ends with the above error message, then try my slightly modified version of the script or you can make the changes yourself as follows.
The problem occurs in this code starting at line 384:
Function GetRefContext( oData, oFpcRef )
Const fpcEnterpriseScope = 1
If oData.fEntEd And oFpcRef.Scope = fpcEnterpriseScope Then
Set GetRefContext = oData.oISA.Enterprise.RuleElements
Exit Function
End If
Set GetRefContext = oData.oCurrentArray.RuleElements
End Function
My fix is to comment out the affected section of code, which appears to be checking for data in the enterprise version of ISA server.
Function GetRefContext( oData, oFpcRef )
' [TPL] Commented out check for enterprise configuration to work around
' [TPL] problems on Small Business Server
'Const fpcEnterpriseScope = 1
'If (oData.fEntEd And (oFpcRef.Scope = fpcEnterpriseScope)) Then
' Set GetRefContext = oData.oISA.Enterprise.RuleElements
' Exit Function
'End If
Set GetRefContext = oData.oCurrentArray.RuleElements
End Function
[UPDATE: A new version 1.2 of the script has been released that fixes this problem. Apparently this was due to an inconsistency in how VBScript processes the If ... AND ... Then construct.]
In a recent legal ruling in Illinois USA, the UK company Spamhause was ordered to pay over $11 million in damages to an American e-marketing company. Spamhause was accused of falsely listing E360 Insight in their database of known spammers. Spamhause did not defend the case and default judgement was entered against them. Spamhause's reply to the court judgement is that since they are a UK company, the Illinois court had no jurisdiction and the judgement is unenforceable.
While this episode is something of a farce, I have always believed it would be only a matter of time before this sort of thing started happening. I have no sympathy for spammers and I believe that Spamhause was probably justified in listing that company in their database, but the big problem with these databases is that anyone can be blacklisted by a third party and there is often little or no recourse. Anyone who has tried to set up an email server on a dynamic IP address will know exactly how frustrating that can be. Simply because your IP address is listed as belonging to a dynamic pool, even if it actually never changes, you'll be on somebody's blacklist. I strongly disagree with that kind of discrimination; making summary judgements about someone's reputation based on some arbitrary attributes decided by a third party, especially when there is no right-of-reply. For that reason, I have always been slightly wary of internet blacklists.
There are better ways to control spam. For example, the Sender Policy Framework, which uses existing technology (the Domain Name System, DNS) to publish a list of authorised servers that are allowed to relay mail for a given domain. Every mail server administrator should now be publishing SPF records. The receiving mail server can then compare the originating IP address in the email header with the list of authorised servers and decide whether to accept the message. The latest versions of Exchange Server 2003 support this feature on the receiving end. There is a handy web page with an overview of how the system works and a wizard for working out what to put in your SPF records. Once you know what your records should contain, you simply create a TXT (text) record on your public DNS server and paste in the results from the wizard. Easy to set up and costs nothing.
Here at TiGra Networks we use GFI MailEssentials to control spam (backed up by Exchange's Intelligent Message Filter). MailEssentials provides a number of different ways to block spam, including internet blacklists, if you want to use them, plus Bayesian analysis, SPF and keyword checking. It also has a handy mailing list feature (for setting up discussion lists and newsletters) and can archive mail to a SQL or Access database.
Something I've been thinking about for a while is how the ASCOM Initiative might be migrated to make better use of the .NET platform. Obviously there is a need for forward compatibility and, in the short term, backward compatibility, but the current implementation requirements for ASCOM represent a barrier to wholesale migration to the .NET platform. This is a discussion document designed to promote more proactive thinking about moving ASCOM forward and creating a roadmap for adopting newer technologies.
First, why do we need to migrate to .NET at all? Good question. The simple answer is that Microsoft is a company that continually reinvents its products and technologies and the old ones linger for a while then become unsupported fall into disuse. Whether we like it or not, that is the nature of life with Microsoft. It would be irresponsible to maintain a development paradigm that is no longer supported by the vendor. The primary development language for ASCOM as of now is Visual Basic 6, which is no longer officially supported by Microsoft. Soon, it will no longer be possible to buy licenses for VB6 and henceforth there will be no more bug fixes or upgrades and over time developers will begin to learn and use Visual Basic .NET or one of the many other .NET development languages. I should not need to reiterate the advantages of the .NET platform, suffice it to say that to ignore these new development platforms and paradigms is to risk rendering ASCOM obsolete and without developer support. As a volunteer led initiative, ASCOM is dependent on volunteer enthusiasm and must take steps to preserve the momentum fuelled by that enthusiasm. Failure to do so is to risk diminishing developer support, perhaps resulting in the demise of ASCOM through developer apathy. ASCOM must evolve to fit the needs of developers and not try to force developers into an ageing development paradigm, or the best developers will desert the project.
Clearly it is not acceptable to discard all of the work done thus far, but neither must the need for compatibility be allowed to stifle innovation. What is needed is a clear, well considered migration strategy that preserves backward compatibility in the short to medium term and aims to fully embrace new development technology in the medium to long term. This should be set out as a clear roadmap so that everyone knows what to expect and when. It would seem wasteful to attempt large changes to the existing infrastructure to achieve the goal of migrating away from it, so I focus here on solutions in the .NET arena, with proposals for minor changes to the existing platform only where absolutely necessary.
To achieve this aim of fully migrating to .NET, I believe the following are needed:
-
A level of abstraction that removes dependence on COM (Component Object Model).
-
Adoption of interface based components to maintain the flexibility of the COM component model.
-
A better versioning system that enables application authors to select their desired level of compatibility without being unnecessarily encumbered with backward- and forward-compatibility issues
What's wrong with what we have now? Well, a few things:
-
Early binding is explicitly forbidden, making it hard to develop against interface definitions and to use strongly-typed components with good IntelliSense support.
-
Different versions of the device standards require different interfaces, requiring client applications to be re-architected and support dual standards.
-
There's no clear roadmap or migration strategy for .NET
-
There's no standard abstract mechanism for binding to a driver, creating technology dependence and potential forward-compatibility problems.
Now those are fairly sweeping statements so I will try to expand on them. Keep in mind that I am focussed on migrating ASCOM to .NET and the ideas I present here are all geared towards that objective, while preserving forward and backward compatibility with existing systems.
Early vs. Late Binding
In its current incarnation, ASCOM dictates that late binding be used, which makes perfect sense given the design goals of ASCOM. However, .NET provides a better way of working that is better than either early or late binding. In .NET the concept of an interface is more powerful. Application software can code against an interface at design time without knowing which object will implement that interface at runtime. This allows strongly typed interfaces to be created and published as part of the standards documentation, while retaining all the flexibility of late binding. This approach lends itself very well to the ASCOM plug-in driver architecture. So my assertion is that in the future, ASCOM drivers should be developed against interface definitions that will be maintained and published by The ASCOM Initiative.
One of the original reasons for the late binding requirement was so that ASCOM device drivers could be used in scripts and as ActiveX controls. With a new breed of scripting engines imminent in the guise of the Windows Power Shell (codename ‘Monad') which can work directly with .NET Assemblies, and ASP.NET web technology that can also interact directly with .NET assemblies, together with the fact that COM Interop maintains backward compatibility, the need for late binding is greatly diminished, if not eliminated. Interface definitions in .NET perform equally or better and make for a stronger programming paradigm.
ASCOM standards definitions should include .NET interface definitions compiled into a .NET assembly DLL and published as part of the ASCOM Platform.
Assemblies that claim ASCOM compatibility must fully implement one of more of the standard ASCOM Device Interfaces.
To facilitate forward compatibility, .NET drivers shall expose their device interface to COM Interop. There shall be a standard pattern for doing this included in the standards documentation.
Standard Abstract Mechanism for Binding to a Driver
The way ASCOM works right now is that a driver is instantiated by name, using the ClassID of the COM component. ASCOM uses the name DeviceID as a synonym for ClassID and hereafter I shall use the two terms interchangeably. ASCOM uses 'late binding' and explicitly forbids early binding using VTable interfaces. This has the advantages of keeping the system loosely coupled and fairly easy to use from scripting languages and Visual Basic. One down side is that it makes life harder for C programmers; nevertheless it is a system that has worked well. So what is the problem? Well, in a nutshell, this way of working relies on a specific component architecture known as COM which, while it isn't going to disappear any time soon, is nevertheless being slowly replaced by .NET assemblies. As already discussed, programming against interface definitions is a stronger technique with many benefits so late binding should not be a prerequisite for developing ASCOM components in the .NET era.
Microsoft has a technology called COM Interop, which allows .NET assemblies to look like COM components and vice versa, using wrappers that are generated dynamically at runtime. This mechanism is crucial to maintaining forward and backward compatibility for ASCOM in the short term. However, I believe that this should not be an obstacle to embracing new development platforms. COM Interop should be regarded as a medium-term bridging technology that, in the fullness of time, will become unnecessary. Therefore, when planning a migration path for ASCOM, COM Interop should not form an central part of that strategy. That is, .NET applications that consume .NET drivers should not need to rely on COM Interop at all, but should be able to load the drivers directly.
Clearly, some level of abstraction is needed to hide all of the complexity of loading drivers and whether or not COM Interop is required. To that end, an abstract way of binding to ASCOM drivers is needed so that applications (and to some extent, drivers) don't need to know what technology is being used. This will reduce technology dependence and smooth the transition from COM to .NET - my suggestion is a DriverFactory class that hides the binding mechanism from the application. So the application would simply request a driver that implements a certain device interface at a certain interface revision for a particular device and the driver factory would go off and find an appropriate driver, load it and return a reference to it (or specifically, to the interface that it implements). The application will not need to know whether the driver is a .NET assembly or a COM component, it will simply make calls against the interface.
ASCOM should provide a DriverFactory class that is responsible for locating, loading and returning a reference to a driver that meets the application's requirements. This class should encapsulate all of the details of version negotiation, locating and loading the appropriate components, be they .NET assemblies or COM components.
Versioning of ASCOM Components
I believe that a more flexible versioning mechanism is required for two reasons:
The example I cite is the evolution of the telescope interface from version 1 to version 2. Telescope V2 added new methods and properties and changed the signature of some existing methods and properties, so that applications needed to be re-architected to take advantage of the new standard. Once a driver was upgraded from V1 to V2, there was a risk the existing applications would cease to function with that driver. Applications that were re-architected to use V2 drivers would either have to jump through hoops to maintain backward compatibility or would cease to work with older drivers.
To some extent, this situation is mitigated by programs such as POTH, which have a built-in translation layer that hides driver compatibility problems. However, it would be better to shield application developers from these transitional problems altogether. I would propose a version negotiation mechanism, whereby an application can declare which interface versions it is prepared to support. The chooser and the driver factory would conspire to provide only assemblies that implement the requested interface versions. Note that it is possible for drivers to implement multiple interfaces and possible for applications to support multiple interface versions, should they choose to do so.
The mechanism I propose is akin to that used by TAPI, the Telephony API. In TAPI, ‘drivers' declare which API versions they are prepared to support, as do TAPI applications. When an application requests a list of the available drivers, a version negotiation takes place that compares the versions supported by the driver to the versions requested by the application. The result is that the application only sees compatible drivers and the optimum interface version. There seems to be a good analogy here with the ASCOM platform.
The advantage of this technique is that both drivers and applications can be updated incrementally without breaking backward compatibility. When new interface definitions become available, drivers can gradually adopt the new interface while continuing to implement the old interface. Similarly, applications can remain backward-compatible with the old interface while gradually adopting the new interface as and when they are ready. Neither applications nor drivers get left behind with compatibility problems.
ASCOM should define a strong versioning mechanism and provide version negotiation services for applications. The Chooser might be a good place to implement version negotiation.
This great little module for Community Server from Ben Tiedt makes it easy to create links to Wikipedia articles in blog posts. The highlighted items in this post are examples of how it works.
The module is simple to install, just copy the files into the CS Web folder and insert an entry into the CommunityServer.config file. Then, in the blog post, use the Community Server text part syntax to create an instant Wikipedia link.
ToDo: work out how to include an example of text part syntax here without having CS process it ;-)