This document outlines the general communications and network bandwidth utilization used in a typical Access It! Universal.NET system. The document is broken into three sections. The first section explains basic communications between the server machine and the access control field panels known generically as SCPs. The second section details the overall communication between the server machine and client machines, while the third section gives typical network bandwidth utilizations on a per transaction basis.
The server machine handles all communications to and from the SCPs. It is important to note that when referring to the server machine it is always in reference to the computer for which the dongle or hardware key is attached. This dongle is a physical hardware key which is programmed with many system parameters. One of these parameters tells the Access It! Universal.NET Server Service how many SCPs may be attached to the system at any given time. This service resides only on the server machine and runs as an executable named AIUniSvc.exe. The service is set to start automatically upon operating system startup by default. This service may be stopped and restarted manually by using the Access It! Universal.NET Service Manger accessible from the Start menu. It is essential that when manually starting or stopping the service that it be performed directly from the server machine and not via a remote desktop session. Once the service is running, it controls all communications to and from the server and the SCPs. Including all configuration records as well as a multitude of transaction types from the SCPs.
The Access It! Universal.NET Server Service is also responsible for all client/server communications. These communication connections are established using Microsoft DCOM RPC port 135 and TCP port 3030. Whenever a client performs a function such as logging into the software, the service handles the database transaction for that client. Once logged into the software, if the client is configured to receive events such as door transactions or alarms, the service will send them to the client as they occur. Should the client need to add, update or delete a record, again the database transaction is handled by the service as needed.
The bandwidth requirements for a typical Access It! Universal.NET system are dependant on the way the system is being utilized. For example if the system does not have a lot of card updates and is not being monitored regularly by a guard, then it will tend to be rather low. If however the system is very active with a lot of SCPs and card updates as well as being used for alarm processing and cardholder verification, it is possible that the bandwidth being used by the server machine may be significant in a smaller sized LAN environment. Generally speaking when it comes to sever and SCP communications, the main concern is the latency in moving a packet rather than the capacity to move packets within the network.
The table below demonstrates a few examples of typical transaction types and their approximate data sizes for each type:
|Transaction Type||Traffic Flow||Approximate Data Size||Comments|
|SCP Poll/Response||Service to SCP||<16 bytes||Every 1.5 seconds with no transactions|
|Cardholder (Add, Update, Delete)||Client to Service||30 – 60 Kbytes||With images|
|Cardholder (Add, Update, Delete)||Service to SCP||0||Not stored in SCP|
|Card (Add, Update, Delete)||Client to Service||500 – 600 bytes||As needed|
|Card (Add, Update, Delete)||Service to SCP||50 – 100 bytes||As needed|
|SCP Reset||Service to SCP||Up to SCP Memory Capacity*||Typically 2 – 5 minutes|
|Panel Transaction||SCP to Service||<80 bytes||As needed|
|Panel Transaction||Service to Client||<300 bytes||As needed|
|Alarm Transaction||SCP to Service||<80 bytes||As needed|
|Alarm Transaction||Service to Client||<300 bytes||As needed|