All TINE servers have the following characteristics:

• Unique Front End Controller Name (FEC) (up to 16 characters in length). As clients must locate the server to which they wish to speak, it is important that no two servers claim to be the same entity. One could argue that in some cases, a certain degree of load-sharing and/or redundancy could be achieved by using two (or more) servers with the same server name.
  Practically, this is difficult to achieve, as the relevant hardware can usually only be accessed from one station. In cases where it is nonetheless feasible to have different access paths to the same hardware, the server processes in question MUST have different names (such as "SRV1" and "SRV1-BAK"). The acronym FEC is sometimes referred to as a Front End Computer . This would be a complete misnomer in cases where two servers reside on the same computer. In such cases, each much have a unique "FEC" name, even though they are both located on the same front end computer.
• Unique Network Address (IP and/or IPX). It goes without saying that the IP address and IPX address of the server is unique on the network. Servers also listen on a specific UDP port (IP), TCP port (IP) and/or IPX socket (IPX) for requests. This listening port is also a part of the server address and must also be unique. In TINE, this is regulated by assigning offsets to a standard listening port. The default offset is 0. Thus for multi-process operating systems such as UNIX, VMS or Win32, all distinct server processes running on the same physical machine (and hence the same IP and IPX address) must have different port offsets.
• Device Servers. All FEC processes consist of one or more "Device Servers," known internally as "Equipment Modules". Device servers interface to the rest of the control system by encapsulating the hardware (or services) they are controlling by exposing and exporting "Properties" of a device type (piece of equipment). Obtaining for instance the beam positions from a Beam Position Monitor Server might be as easy as asking for the property "POSITIONS" or "ORBIT". Device Server Names are exported as a unique name which can be up to 32 characters in length. In addition, the equipment module has a "local" equipment module name used by the TINE kernel for de-referencing and managment purposes.
  This 'local' equipment module name is up to 6 characters in length, is hard-coded, and must be unique only within the process. So there can be two distinct device servers exporting device server names "BPM.NORTH" and "BPM.SOUTH" but running the same code, where the local equipment module name "BPMEQM" is hard-coded.
• Plug-and-play functionality. If there is a configured TINE name server, all servers register their server names and addresses upon startup. The name server guarantees that there is only one entry with a given server name. A given server can replace an existing entry only if that entry is no longer active. Specifically, if a server tries to reuse a name already present in the name server's database, the name server queries the old entry to see if it is still active. Only if it does NOT respond to this query, is the server name's address replaced. In generally, this functionality allows "painless" replacement of ethernet cards or migration of servers to other machines, activities which would otherwise involve the updating of a database by hand. Likewise the device server names from a particular server as also registered with the name server upon startup. The same guarantee for uniqueness applies to the equipment function names as well. The counterpart to this plug-and-play scenario is played by TINE clients, which we will come to shortly.
• Exported Properties. The Properties which are exported by a device server are not registered with the control system name server, but instead with the local device server. Properties of a device server are thus queriable from the device server only. Property names can be up to 64 characters in length. Properties MUST be exported (see below) in order to be accessed via other clients on the network.
• Device Names. Device servers make use of device names to identify specific "instances" of a device. A device name can be up to 64 characters in length. In cases where device numbers are preferred, a device name in the manner of "#1" is preferred. The Device names are queriable from the local device server.
  If no device names are registered, a query simple returns a list of "#1", "#2", etc. for the total number of devices (a quantity which must be registered).
• Synchronization. TINE servers are typically synchronized to the same designated "time" server. On several platforms, this implies an ntp daemon. Optionally, TINE servers can synchronize data timestamps making use of an external TINE time server, which multicasts (or broadcasts) the system time at regular intervals (typically at 1 Hz).
• Local Alarm Server. The TINE alarm system is such that the first layer of collecting, sorting and filtering of alarms takes place at the server level. Thus, there is a local alarm server task which exists on all TINE servers.
• Local History Server. All TINE servers can maintain both long-term and short-term histories of given properties. This can be achieved via a startup configuration file (history.csv or fec.xml) or API call, where the targeted properties are listed, along with long-term and short-term history depths, and filtering rules.
• Multi-tasking. TINE supports some form of multi-tasking on all platforms, including MSDOS. Namely, on single-threaded servers, background tasks registered along with a device server can be suspending or delayed via API call without upsetting other server operations as long as this is done in a cooperative manner. Where threads are available (Win32, POSIX) or VxWorks tasks, the registered background tasks run on individual threads and define a preemptive multi-tasking system.
• Realtime-safe, Thread-safe. The TINE server kernel is realtime-safe and thread-safe when used in realtime and/or multi-threaded environments. As mentioned above, the TINE server kernel works by default out of one thread in one process. Calls made from the client API from different threads are 'trivially' thread-safe in that re-entrancy is blocked (with an error code) if a second thread attempts to call a routine that another thread has called and the call is not completed. Where threads are available, the equipment module access can be configured to run on a separate thread from the TINE engine. This has the benefit of being able to return information to a client (operation busy, for instance) even if the equipment module is blocking access for some reason. In most cases, running equipment module access in a separate thread should be avoided, since it adds unnecessary latency to transactions.
• Security. All TINE servers support both user-specific (soft) and address-specific (hard) security features. This comes into play when server requests with WRITE access are made.
  If activated, a WRITE request is checked to see if the user making the request is a member of the WRITE-allowed users. Similarly a WRITE request can also be checked to see if the network node from which the WRITE request originated is a member of the WRITE-allowed nodes and networks. Targeted client application can also obtain an 'access lock' to a server, insuring that only the designated application has WRITE access to a server (see the stock property ACCESSLOCK).
• Distributed Initialization Database. TINE does not rely on a central database. Specific database support can be implemented as needed. Server initialization regarding name and address resolution, alarm information, and the like is distributed and server specific.
  All such information is queriable after-the-fact, and can be reassembled into a central database if desired. The lowest common denominator for a distributed database for all platforms is a standard ASCII CSV (comma separated value) file for the pertinent information.
• Stock Properties. TINE servers allow a variety of information to be queried at any time. Consequently, all TINE servers support and respond to a set of standard, i.e. stock properties. A handfull of these refer specifically to the FEC process itself and are actually independent of the server.
• Meta Properties. TINE servers allow a variety of property meta information to be queried at any time. Consequently, all registered properties respond to a set of meta properties, which provide additional information about a specific property (such as its history, units, settings, etc.).