Home/Support / Knowledge Base / Port-sensitive/realtime application workaround for RealPort drivers

Port-sensitive/realtime application workaround for RealPort drivers

This article is written to address an issue that certain customers have reported to us who have port-sensitive applications (for lack of a better term).

What I refer to when I say "port-sensitive application", is an application which polls a serial port to determine whether it exists or not. It may then perform other actions based on the existence or non-existence of the port.

One example of such an application might be a central monitoring facility which polls various serial devices on a network, to make sure those devices are present and accounted for. If a device is not present, the application may route traffic to some other location, notify an administrator via e-mail/pager, or perform some other action.

The problem such an application encounters when used on a Realport device, is that Realport is designed to recover from things like spurious network outages or interruptions without loss of data. In other words, we do not tell the application the serial device is not there, because our expectation is that it will be soon (i.e. the network will recover), and that data transmission will continue. This works very well as a matter of fact, as we once pulled an Ethernet cable during the middle of a print job to test our ability to recover from a network outage. When we came back the next morning and plugged the Ethernet cable back in, the printer continued printing without having missed a character. This is how the Realport driver is intended to work.

Since the driver is working as intended, the best way of dealing with an application requirement of this nature is by adding a "watchdog" to the application itself.

A trivial example of watchdog code is in our ditty command. Because the port could block on open, we do:

 

    (void) alarm(1) ;
    fd = open(tp, O_WRONLY | O_NDELAY) ;
    (void) alarm(0) ;

    If the port cannot be opened within 1 second, the alarm will go off, which cancels the open() call.

    This works with all of our drivers and is the preferred method to timeout any pending calls, since the way the driver works is the way most of our customers wanted it to.

    Last updated: Aug 23, 2017

    Filed Under

    Network

    Recently Viewed Articles

    No recently viewed articles
    Contact a Digi expert and get started today! Contact Us