| Topic | Description |
| How can I make broadcasts span subnets? |
If you have the right sort of routers connecting your subnets, you can extend broadcasts between subnets, using either "helper" settings, or by enabling "Directed broadcast" support.
Having support for UDP broadcast propogation between networks enabled on routers by default is now deprecated, you will have to make this setting yourself, with a full understanding of the risks of enabling broadcast propogation. A few years ago, Cisco routers were shipped with directed broadcast support enabled, and a bunch of bad people developed the "smurf" attack, which exploited this feature to launch denial-of-service attacks.
Before enabling directed broadcast support on a network which is connected to the internet, ensure your border routers comply with the advice given in the best practice document RFC2827
Point your network manager at Cisco - UDP Broadcast Flooding |
| How is the Redirector licenced? | The Redirector is hardware locked to the MAC address of the machine that it is installed in. |
| Where are the Baud Rate and other serial parameters set? |
These setting are made in your application.
The Redirector doesn't actually care what these settings are, as the created Virtual Serial Port to which your application connects will behave exactly as your application configures them. |
| Why does my application see data it has sent? |
In any mode where data is broadcast, the sender will see back the data it has sent, as well as receive data others have transmitted.
This behavior is normal for an RS485 type application, as there is only one serial "bus" common to all devices on it, so they see the messages they send. |
| Why does the Redirector not have flow control |
Before answering this question, it is important to understand why flow control is used.
Flow control is used to prevent a receiving device being overrun with data, ie data is delivered to the port at a faster rate than the application can consume it. With a real physical serial port under an operating system such as DOS, if the application didn't directly service the incoming data quickly enough the UART chip buffer (usually 16 bytes) would be filled and thus data lost.
Under Windows, the physical ports are serviced by Windows, which can buffer significant amounts of data. Applications subsequently ask Windows for this data, which Windows delivers from its buffers.
Under stress testing, the Redirector has been megabytes of data "behind" in terms of servicing, but Windows has all the data buffered up, so eventually all the data gets processed, without data loss.
The Redirector was originally designed to operate with systems that transmit relatively short messages, in a polled type environment. Such messages would never overrun the Redirector. Even when tested with large data streams, no problems have occurred.
Additionally, it is difficult to define exactly what flow control should mean in a many-to-many environment. Thus it is unlikely that we will attempt to add flow control support to the Redirector.
The only final answer is for you to test the Redirector in your environment, and determine if the lack of flow control is an issue for your applications. |
| Why does the Redirector use UDP? | Using UDP, and more specifically, UDP Broadcast allows a number of operational modes that cant be delivered using TCP. |