Universal Messaging 10.3 | Administration Guide | Universal Messaging Enterprise Manager | Administration Using Enterprise Manager | TCP Interfaces, IP Multicast and Shared Memory | Interface Configuration
 
Interface Configuration
Each interface on a Universal Messaging Realm has a number of configurable attributes that determine the interface behavior. Some of these attributes are standard across all types of interface protocols, and some are specific to a particular protocol.
This section will describe the attributes that are common to interfaces of all types.
For additional information on specific interfaces types, see TCP Interfaces, IP Multicast and Shared Memory.
Basic Interface Attributes
When an interface is selected from the table of interfaces on the Interfaces tab, there are a number of attributes that are configurable for the interface. Below the interfaces table, there is a set of tabs, one of which is labelled Basic, as shown in the image below.
The basic interface configuration panel shows configurable attributes. These are explained in the following section:
Accept Threads
Each Universal Messaging realm interface contains a server socket. The Accept Threads attribute corresponds to the number of threads that are able to perform the accept() for a client connection. The accept() operation on a Universal Messaging interface performs the handshake and authentication for the client connection. For more heavily utilised interfaces, the accept threads will need to be increased. For example, on an nhp (http) or nhps (https) interface, each client request corresponds to a socket accept() on the interface, and so the more requests being made, the busier the interface will be, so the accept threads needs to be much higher than that of say an nsp (socket) interface. Socket interfaces maintain a permanent socket connection, and so the accept() is only performed once when the connection is first authenticated.
Advertise Interface
All interfaces that are advertised by a realm server are available to users (with the correct permissions) of the Universal Messaging Admin API. This property specifies whether the interface is indeed advertised to such users.
Alias
Each interface on a Universal Messaging Realm Server can have an associated alias in the form of host:port. This alias can be specified here.
For information on interface plugins please see Interface plugins.
For information on adding VIA rules for an interface please see Interface VIA Rules.
When you change any of these attributes, the changes need to be applied by clicking the Apply button. For more information, refer to the modifying interfaces documentation (see Modifying Interfaces).
Allow Client Connections
If this attribute is activated, clients are allowed to connect to the realm over this interface.
If this attribute is deactivated, clients are not allowed to connect to the realm over this interface. Note that Administration API connections, e.g. Enterprise Manager, count as client connections, so at least one of the available interfaces should allow such Administration API connections. If a realm has been defined with only one interface and you deactivate the Allow Client Connections attribute on the interface, this setting will be ignored. This is because essential administration tools like the Enterprise Manager would not otherwise be able to access the realm.
Allow for InterRealm
If this attribute is activated, the interface can be used for any of the following kinds of internal communication (i.e. Universal Messaging's own message passing) between realms:
*Inter-realm communication: between realms in the same cluster.
*Inter-zone communication: between realms in a zone.
*Inter-cluster communication: between realms in connected clusters.
Important:
If you do not activate this attribute for the interface, the interface cannot be used for any of the above scenarios.
If you activate Allow for InterRealm and deactivate Allow Client Connections for the same interface, the interface can only be used for internal communication between realms, so no communication with an external client is possible using such an interface. There are situations in which this configuration can be useful. For more information, see the section Setting up Inter-Realm Communication.
Autostart Interface
The Autostart attribute specifies whether the interface is started automatically when the Universal Messaging realm server is started. When this option is not selected, the interface must be started manually in order for it to be used by connecting clients. Please note that if Autostart is not set it must be started either manually or using the Universal Messaging Administration API whenever after the realm is started.
If Autostart is selected then the interface will be started once the Apply button is pressed.
Auth Time
The Auth Time attribute corresponds to the amount of time a client connection using this interface can take to perform the correct handshake with the realm server. For example, the default is 10000 milliseconds, but for some clients connecting on slow modems, and who are using the nhps (https) protocol, this default Auth Time may need to be increased. If any client connection fails to perform the handshake in the correct timeframe, the connection is closed by the realm server.
Backlog
The Backlog attribute specifies the maximum size of the incoming IP socket request queue. The operating system that the realm server is running on may specify a maximum value for this property. When the maximum queue size is reached the operating system will refuse incoming connections until the request queue reduces in size and more requests can be serviced. For more information on this value, please see the system administration documentation for your Operating System.
Enable HTTP 1.1
Enable the usage of HTTP 1.1 protocol on this interface.
Enable NIO
Specify whether NIO should be used for this interface.
Receive Buffersize
This specifies the size of the receive buffer on the socket
Select Threads
The Select Threads option specifies the number of threads allocated to monitor socket reads/writes on the interface if NIO is enabled. When a socket needs to be read, these threads will fire and pass on the request to the read thread pool. If the socket is blocked during a write, then when the socket is available to be written to, these threads will fire and the request will be passed on to the write thread pool. The number of select threads should not typically exceed the number of cores available.
Send Buffersize
This specifies the size of the send buffer on the socket.