Embedded transport servers > PeSIT (embedded) fields

PeSIT (embedded) fields

An embedded PeSIT server is available after a community adds a PeSIT transport for picking up messages from integration or a PeSIT transport for receiving messages from partners. You can change the server’s settings and advanced options.

To change settings:

Select System management > Manage embedded servers. Or, click Trading configuration on the toolbar.
On the Communities page, click the link near the bottom of the page named Manage all embedded servers.

The following are the maintenance fields for an embedded Transfer CFT (PeSIT) transport server that has been added by a community.

Settings tab

Server name – A name you give the transport server to distinguish it from other embedded servers. This field gets its initial value when you type it in the delivery exchange wizard.
Host – The fully qualified domain name of the computer on which the embedded server runs. Activator detects this setting; you cannot change it.
Port – The port on which the server listens for connection requests.

Advanced tab

Minimum threads –The least number of threads must dedicate to the server.
Maximum threads –The most threads can dedicate to the server.
Read timeout (seconds) – How many seconds of inactivity to allow before Activator terminates the connection.
Server timeout (milliseconds) – Controls how long the server waits after receiving a file to see if the client is going to be sending another file on the same session. Setting this too low may cause abort errors on the client side. Setting this too high may cause tread pool depletion on Activator side.
Connection timeout (seconds) –Time in seconds Activator waits for a connection to the delivery exchange before the attempt times out. Although the default value is 30 seconds, this may be longer than the interval allowed by your operating system (OS). For example, Windows XP by default allows a maximum timeout of 20 seconds. The actual connect timeout interval is the lesser of the OS timeout and the value set in Activator.
Transfer timeout - server mode (seconds) – Time in seconds a transfer times out.
Network timeout (seconds) – Time in seconds the network times out.
Protocol timeout (seconds) – Time in seconds the protocol times out.
Send buffer (resize) – This represents the largest of chunk of data, in bytes, to be transferred at one time. For high-speed networks, this should be 32,700 bytes, which is the default value.
In addition, this value is related to the client setting for record length on the PeSIT parameters tab. The value of this field must be the same or larger than the value of the record length field.
Do not change this value unless advised by the administrator of the component.
The parenthetical term after the field name (rusize) is the term for this setting.
Kb per sync point (pacing) – Each time an amount of data equal to this value has been sent, the client is expected to ask the server to confirm whether data totaling this value has been received. The server responds optionally with a confirmation. This represents a check point in the progress of a file transfer. If a connection is lost before a file transfer has been completed, the transfer resumes, upon restart of the transport, at the point of the last successful check point.
The default value is 1024 kilobytes (1 megabyte). Do not change this value unless advised by the administrator of the component.
The parenthetical term after the field name (pacing) is the term for this setting.
Max outstanding sync points (chkw) –This controls how many check point cycles the client waits for the server to respond to a request to confirm file-transfer progress. For example, if the value of Kb per sync point (pacing) is 1024 (1 megabyte) and the value of this field is 1, the client stops sending data after 1024 kilobytes unless the server responds, although the transfer remains active. If this value is 2, the client keeps sending until 2 megabytes (1024 x 2) of data are sent, and so on.
If the client’s value for this field is 0 (zero), the client does not ask the server to confirm at intervals the amount of data received. If the server’s value for this field is 0, the server does not send confirmations at intervals of data received.
The default value is 3. Do not change this value unless advised by the administrator of the component.
The parenthetical term after the field name (chkw) is the term for this setting.
Override SSL and TLS cipher suites – Select this option and then use the Add and Remove buttons to specify the cipher suites supported for the embedded server.
If you do not select this option, all cipher suites are supported by default. Keeping the default cipher list is less secure than specifying a restricted set of cipher suites.
The cipher suites that are displayed in the "Available" column depend on your runtime environment (JRE version, IACK or FIPS enablement, ....).
The default order in the "Available" column is the preferred order of use. Once ciphers are moved to the Selected column, you can arrange the order. Activator uses the ciphers in the order listed.
A cipher suite is a collection of security algorithms used in making connections via Secure Sockets Layer or Transport Layer Security. For example, an SSL or TLS protocol requires signing messages using a message digest algorithm. But the choice of algorithm is determined by the particular cipher suite being used for the connection. Typically, you can select an MD5 or SHA digest algorithm.
Of the many algorithms for encrypting data and computing the message authentication code, there are varying levels of security. Some provide the highest levels of security, but require a large amount of computation for encryption and decryption. Others are less secure, but provide rapid encryption and decryption. The length of the key used for encryption affects the level of security. The longer the key, the more secure the data.
The option for overriding cipher suites lets you select the level of security that suits your needs and enables communicating with others who might have different security requirements. For example, when an SSL connection is established, the client and server exchange information about the cipher suites they have in common. Then they communicate using the common cipher suite that offers the highest level of security. If they do not have a cipher suite in common, secure communication is not possible.
In versions of Activator earlier than Activator 5.9, cipher suites configuration was handled by a file named sslciphersuites.xml. As data in that file is saved in the database, the custom cipher suites configuration is retained upon upgrading and is displayed in the Selected list under the option in the user interface. The sslciphersuites.xml file is no longer used.