www.digi.com
  Advanced Search
Product Selector
     
  Technical Support
Drivers

Firmware Upgrades

FAQs

Product Documentation

Cabling

Support Tools

Legacy Products

About Digi Support

Knowledge Base

Online Support Request

FTP Site



Related Links
Inside Out Networks


 
Solutions Partners Support and Training Corporate Info Where to Buy Order Where to Buy Site Map Contact Us
Home > Support >kbase >
Port-sensitive/realtime application workaround for RealPort drivers
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 don't tell the application the serial device isn't 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 can't 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. 

solutions | partner programs | corporate info | support and training | where to buy
site map | contact us | press releases |
events | promotions | advertising

Copyright © 1996-2001 Digi International. All rights reserved.