I have a security system (ARES) setup running over a cisco controlled VLAN.
ARES is designed to run on the Fleet protocol on LANs 10/100mg links
Node 1 is the server and stores the Full Database, Node 2 is a workstation and needs Node 1 online to work.
Location 1 Node 1 running on a 512k link
Location 2 Node 2 on a 2mb link.
Links controlled by ISP
My problem is this
when a pure tcpip device (serial-to-TCPIP device) at location 2 connects to Node 1 there is negligible delay. And Node 2 gets message.
The problem occurs when the Node 2 tries to change/report on someting in the database, it can take upto 5hrs for a report come through ( an empty one btw) or upto a minute for a db change.
I’m missing something, are the transaction going through TCP/IP or through FLEET. Can the VLAN support FLEET or is FLEET embedded in TCP/IP (via unsupported program called infleet).
If the ping trip is 140ms you are in trouble. FLEET is design to run over rather fast (and stable) medium. I’m guessing the database are made up of lots of small messages/transaction which makes matter worst. I know FLEET over a 115kb serial link can’t keep up with something as slow as typing Still 5hrs seems exessive.
Maybe you could sniff the traffic to see what is going one. Run netinfo -l(el) to check for network error (maybe post the result here).
As one of the developers of this product I feel some explanation is in order.
This particular installation has two nodes running from one end of the country to the other (Melbourne to Perth)over a WAN. We are using infleet to encapsulate FLEET into TCP/IP. This normally works very well, but there appear to be network issues involved in this installation. Apart from the very long ping times we have been informed that the packets are being delayed in a router at one end. and if there’s one thing that kills the performance of FLEET it is delays.
The customer has been informed that a speed increase is possible by simply swapping the locations of the nodes so that the report runs on the node where the database is stored. The report could be generating millions of SRR actions.
The reason the device on node two has negligible delays is because it is normally only connecting to other process on the same node.