Contents
Introduction
Late march this year my company has been asked to take part in a joint project to deliver a complete congress solution for a major government organization here in Slovakia. The hardware was the Philips Digital Congress Network (DCN, see links [^]) line of products and my company had to develop new control software for the DCN Central Control Unit (CCU).
I took over the software part of the project and started analyzing the requirements. Here they are in a nutshell:
- Write a serial protocol handler to communicate with the CCU using its custom protocol.
- Write a set of end-user applications to control and manage the various subsystems found in the CCU, such as microphone management, voting, delegate registration, access control, etc.
The "funny" part of this project turned out to be the protocol handler, mainly because the protocol specifications were a bit incomplete and imprecise (and I'm very tolerant with this wording;-).
The protocol basically describes how to transfer messages between the CCU and the controlling PC. The message data are opaque streams of bytes. The actual structure of the data is implied by the message type, which is defined in the documentation using C-style syntax. For illustration, here is the definition of a message that the CCU sends when a delegate inserts a PIN card into her delegate unit (don't worry about the semantics, its not important for this discussion):
typedef struct
{
WORD wUnitId;
WORD wDelegateId;
BYTE byAttend;
} AT_T_DEL_ATTEND;
Because there are lots of different message types defined, I wanted to design some generic mechanism that would allow me to:
- Easily define the structures as VB.NET classes.
- Automatically handle the conversion of the classes to and from byte streams transmitted over the serial line.
In other words, I wanted to provide a kind of remoting infrastructure for transferring .NET objects across the serial line. Reflection seemed to be an ideal tool for solving this kind of problem.
I came up with the following design:
The CcuSerializable attribute can be applied to a class or a field to control the serialization process.
The SerializationManager class that implements the actual serialization and deserialization of CcuSerializable objects to and from byte streams. SerializationManager uses Reflection extensively to interrogate a set of CcuSerializable fields for a given class, as well as to actually write and read the fields' values to and from byte streams, for example:
Private Sub SerializeInteger( _
ByVal obj As Object, _
ByVal field As FieldInfo, _
ByVal attr As CcuSerializableAttribute, _
ByVal writer As System.IO.BinaryWriter)
Dim Value As Integer = CInt(field.GetValue(obj))
writer.Write(Value)
End Sub
Private Sub DeserializeInteger( _
ByVal obj As Object, _
ByVal field As FieldInfo, _
ByVal attr As CcuSerializableAttribute, _
ByVal reader As System.IO.BinaryReader)
Dim Value As Integer = reader.ReadInt32()
field.SetValue(obj, Value)
End Sub
You can find a link to the complete SerializationManager source code at the end of this article. (Yes, complete code; taken straight from the project and placed on my website. For you:-)).
With SerializationManager, implementing the various control applications was easy. I've had just to tag the serializable classes with the CcuSerializable attribute like this...
<CCUSERIALIZABLE()> _
Public Class AttnEntry
<CCUSERIALIZABLE()> Private _UnitID As Short
<CCUSERIALIZABLE()> Private _DelegateID As Short
<CCUSERIALIZABLE()> Private _Status As Byte
...
...And the rest was handled automatically.
That's it.
Well, the project isn't completed yet. It will enter beta testing at the beginning of August (this year;-). The software will control over 150 delegate units and I've tested with just 15 so far. Nevertheless, I'm quite confident that the software will survive the load of the production environment and that the use of Reflection won't be a problem. Stay tuned, I'm going to write another article after the project completes.
(And please, don't worry--I'll be honest and tell you when something would go wrong. After all, VBInfoZine is about real projects and they have a tendency to fail sometimes:-)
© Palo Mraz - Monday, July 14, 2003
Top 
Links
http://msdn.microsoft.com/msdnmag/issues/02/10/NETSerialComm/ [^] - John Hind's article about serial communications in .NET. Accompanied with C# source for the CommBase class used within the project described here.
http://www.philipscsi.com/ [^] - The makers of the DCN product line. Formerly Philips Communication, Security & Imaging, now owned by Bosch.
Top