A Ceptor Agent, is a client towards the Ceptor Server.

The agent exists as a Java .jar file, as a .NET Assembly and most methods are available as a REST service (Agent REST Service).

The agent is embedded in several Ceptor components, e.g. the Ceptor Dispatcher and the Ceptor Gateway.
It is also embedded in any Application Server Integrations. 

An Agent connects to a Ceptor Configuration Server to obtain its configuration - it keeps this connection alive, and can receive configuration updates as well as forward its collected statistics to the statistics server via the config server.

The Agent will also connect to the Ceptor Session Controller and act as the interface to the session controller from an application or service - implementing the API that the session controller exposes.

An application that uses the SessionController does not itself set up a socket to it, and send data back and forth, but it instead uses the Agent, which then keeps the connection to a SessionController, as well as caching sessions, to minimize network traffic.

Clustering

A Ceptor Agent is connected to one, and only one Configuration Server at a time, and it is also connected to only one Session Controller at a time.

Once the connection is established, the TCP/IP socket stays open which greatly reduces the overhead of sending a command to the server – only if the connection breaks, of if consecutive errors are occurring on a connection, then the Agent will switch to another server.

This means that the Agent itself does not do load balancing towards the Session Controller, but it stays connected to the first available one until the connection breaks. Extensive testing has shown that there is little or no performance gain by load balancing request towards different Session Controllers.

If your setup contains hundreds of agents, you might wish to share the load between more machines, in that case you can use dynamic load balancing, see the section about this later in this document.