Basic TCP Protocols

“Generic Server First”, “Generic Client First” and “Generic Streaming” protocols are the most basic L7 protocol types that the Virtual Traffic Manager can use. They are useful when managing custom protocols or simple TCP connections because they do not expect the traffic to conform to any specific format.

Server-first is the simplest TCP protocol type. When the Virtual Traffic Manager receives a connection from a client, it immediately runs any TrafficScript request rules, then immediately connects to a back-end server. It then listens on both connections (client-side and server-side) and passes data from one side to the other as it comes.

Server-first protocols include one-shot protocols such as Time (where the server writes the response data, then immediately closes the connection), or complex protocols like MySQL (where the server opens the dialog with a password challenge).

The virtual server protocol type “Generic Server First” is most suitable for protocols where the server speaks first. In practice, the design of most protocols means that “Generic Client First” is more appropriate.

Client-first is a modification of server-first, appropriate for protocols where the client connects and sends a request before the server replies. You can use the “Generic Client First” protocol type to inspect a client’s request and select a server pool that should be used to select the server node to be used.

The Virtual Traffic Manager is only alerted when a client connection has been established and data has been received. The Virtual Traffic Manager then proceeds in the style of server-first: runs TrafficScript rules, connects to the back end and relays data back and forth.

The Virtual Traffic Manager alternates between running TrafficScript request and response rules. It will run the request rules when the first data from the client received; the request rules may block if they use functions like request.getLine() or request.get() to read further data from the client.

Once the request rules have completed, the Virtual Traffic Manager will forward any further data it receives from the client on to the server. The Virtual Traffic Manager will run the response rules as soon as it receives any data (in other words, a “response”) from the server; these response rules may also block.

The Virtual Traffic Manager will then continue to forward any further data from the server to the client; the Virtual Traffic Manager will wait for any data from the client and run the Request rules again; in this manner, the Virtual Traffic Manager switches between waiting for request data to run request rules, and waiting for response data in order to run response rules.

Note that rules that are configured as “Run Once” rather than “Run Every” will only be run on the first server or client data, not on subsequent iterations.

Server-first with a server banner is a different optimization for “server-first” to cater for servers which broadcast a banner on connect, such as SMTP. “Server-first with server banner” allows you to inspect and make a load-balancing decision based on the client’s request.

When a client connects, the Virtual Traffic Manager immediately writes the configured server-first banner to the client, then proceeds as a regular client-first connection. In addition, the Virtual Traffic Manager slurps and discards the first line or data (terminated by a newline) that the server sends.

Use TrafficScript rules to inspect the client's request data before making your load-balancing decision.

To configure this behavior, select the "Generic Server First" protocol type and configure a banner message in the Protocol Settings section in the virtual server configuration.

If you are using a protocol that does not require the server to respond to every message that the client sends, or if you need extra flexibility when processing data in TrafficScript, you can choose the “Generic streaming” option. This server type allows either the client or server to send the first message when a connection is established and also allows TrafficScript rules to be invoked whenever data is received on the connection.

This option is for protocols where there is no request-response semantic. Either side of the connection can write the first message, with no response being necessarily required or expected. TrafficScript request rules are run whenever the client writes data on the connection, and similarly response rules are run every time the server writes data on the connection.