RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Create a Syslog Sender/Receiver Using the MS Winsock Control

With the Microsoft WinSock Control and a few coding tricks, you can use Access as a high-performance syslog sender, receiver, and logger.

"ary! Bob! Dinner in 10 minutes," you yell out the kitchen window because you know the kids are outside somewhere. You transmit a simple message to a known receiver. Usually, the message is received and understood, and the hungry kids show up, but sometimes they may not hear you (so they say, anyway). When that happens too often, you may yell the message twice to make sure it gets through.

The 10 minutes pass and still no kids. You call again and your voice becomes a bit sharper: "Mary, Bob. Dinner NOW!" The severity of the message increases.

Syslog works much the same way as you do in this scenario. It is a very simple method for transmitting a simple message across the Internet (from one machine or host to another) without knowing for sure if the receiver is actually listening (is online) and without receiving any confirmation in return. You can view it as texting (SMS) on cell phones transferred to the Internet.

The major advantage of syslog is its simple form: It is just one ASCII text string. As explained in this article from Microsoft, it doesn't require much code to send and receive a syslog message if you use the WinSock Control. This control takes care of all the hard work involved with low-level communication on an IP network. However, using WinSock Control for this purpose isn't trivial. You have to build a syslog message string that conforms exactly to the standard, decode a received message, and split the message into parts to allow you to store it in a database record, which has separate fields for every part of the message.

Ways to Improve syslog Reliability

Though a proposal for a newer syslog standard includes reliability as a feature, reliability was not part of the original standard. In fact, syslog would lose some of its simplicity if it were to adopt this feature. However, you can ensure reliability in the current standard. The solution is to build your own syslog sender and receiver and expand them to two-way communicators that act like this:
  1. Sender sends message.
  2. Receiver receives message.
  3. Receiver returns another syslog message as confirmation.
  4. Sender receives the confirmation message.
  5. Sender records the original message as received.

Steps 1 and 2 represent the normal behavior of a syslog transaction. Steps 3 and 4 add a confirmation message to the transaction. Step 5 logs the transaction. If step 4 fails, either the original message or the confirmation message will be lost, and after a little while the sender will resend the message. The sender will continue resending the message until it receives a confirmation message or it reaches a maximum count of resends. This solution is not only very simple, but it adheres to the standard as well. However, the implementation is beyond the scope of this article.

A poor man's alternative for raising the reliability of syslog—or any kind of UDP transmission—is to resend the packet three times. Should one or two packets get lost because of contention on the network, at least one will get through. This article demonstrates this technique in the frmSyslogSend form.

So what are the drawbacks and limitations? Some of the security limitations are listed here. Other drawbacks are more related to the hand-coding required to craft a syslog message string. (See Sidebar 1. The Alternatives: TCP and Windows Eventlog.)

The Setup Before You Start

The sections to follow demonstrate how to set up a MS Access database as a syslog sender/receiver using the Winsock Control. It uses an example application as the reference demo (click here to download the demo source code). The setup requires a great deal of code, mostly for building or parsing a syslog message and for verifying the parts of a message. For that reason, this article does not outline every single step for recreating the demo. You can extract the demo file syslog.mdb instead of creating the example yourself. If you want only the code, both code modules (basSyslog.txt and basWinAPI_Hostname.txt) are also available in the download.

The demo database files contain the following components:

  • A table (tblSyslog) for storing received syslog messages. This table simply helps to demonstrate the code you'll need when applying this technique to your own database.
  • A module (basSyslog) that contains all the functions to create and parse a syslog message. All functions have in-line comments, which explain much of the code's purpose and function. It uses ADO to store the received messages, so be sure to set a reference to that library.
  • A module (basWinAPI_Hostname) with a collection of functions to retrieve the machine hostname, which must be used to identify the sender of a syslog message. You need to add this module to your own database. You should use this module as is; do not change the names of any constants or calls.
  • A collection of forms for sending or receiving syslog messages.
  • A simple query (qdySyslogData) for displaying the syslog table with the calculated Priority values and the length of the stored messages.
  • A simple query (qdySyslogPacket) for displaying reconstructed syslog packets from their stored parts.

The WinSock Control

The actual transmission of syslog messages between your application and Windows is left to the WinSock Control, which came with Visual Basic 6 and some old versions of the Access Developer Tools. Further, you can download the control from several places, which include tools to correct a corrupted install.

You may not be able to use the control because Internet Explorer has marked it as blocked in the registry. The fastest way to get around this is to run the reg file (WinsockCompatibilityFlagReset.reg) from the demo download. Alternatively, you can manually edit the registry (read the key in the reg file), but if you aren't that brave, just download and run the ActiveXHelper tool. Under Microsoft Vista (and sometimes under Windows XP too), you must run the tool as Administrator. When launched, use the tool to locate the WinSock Control, mark it as Enabled, and save.

With that, your setup is complete. Notice, however, that some of the regular updates from Windows Update disable this flag again, so you will have to repeat this procedure.

Close Icon
Thanks for your registration, follow us on our social networks to keep up-to-date