Server-first and Client-first Protocols

'Server-First' and 'Client-first' protocols are the most basic L7 protocol types that ZXTM can use to manage traffic. They are useful when managing custom protocols or simple TCP connections because they do not expect the traffic to conform to any specific format.

This FAQ describes the difference between 'Server-First' and 'Client-First' protocols, and explains some of the details of managing them.

Client-first and server-first virtual servers work as follows:

Server-first protocols

Server-first is the simplest. When ZXTM recieves a connection from a client, it immediately runs any TrafficScript™ 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.

Load-balancing a simple server-first protocol, such as TIME or MySQL

Server-first protocols may be 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).

Client-first Protocols

Client-first is an optimization of server-first. On the client-side, ZXTM is only alerted when a connection has been established and data has been received. ZXTM then proceeds in the style of server-first, i.e. runs TrafficScript rules, connects to back-end and relays data back and forth. In practice, you can use server-first any time you use client-first, but client-first is more efficient when a client is expected to write the first data.

Load-balancing a client-first protocol such as HTTP

When you use a client-first procotol, you can use TrafficScript rules to inspect the client's request data before making your load-balancing decision.

Server-first with 'server banner'

Server-first with a 'server banner' is a different optimization (to cater for servers which broadcast a banner on connect, such as SMTP). When a client connects, ZXTM immediately writes the configured 'server-first banner' to the client, then proceeds as a regular client-first connection. In addition, ZXTM slurps and discards the first line or data (terminated by a \n) that the server sends.

Load-balancing a simple server-first protocol with a greeting banner, such as SMTP or FTP

Once again, you can use TrafficScript rules to inspect the client's request data before making your load-balancing decision.

Troubleshooting Protocol problems

Timeouts

All connections have associated timeouts on connect and data. If a connect does not complete within the 'connect' timeout, or the connection is idle for the 'idle timeout', the connection will be discarded.

If it's a server-side connection, it will count as a server failure; three successive failures mark the node as dead.

The timeouts and 'three-failures' count can all be tuned if necessary via the Connection Management settings in the Virtual Server and Pool, and the Global Settings page.

Deadlocks

A request or response rule can cause the connection to block. For example, if ZXTM runs a request rule that calls 'request.read()', the connection will block until the required data has been read from the client. During this period, ZXTM stops relaying data from the server.

This may stall a connection or even trigger a timeout; be very careful if you use read (or write) TrafficScript functions with a bi-directional protocol. Take a look at chapters 3, 4.6 and 5.4 in the TrafficScript manual.

More information

The following articles describe how ZXTM processes TrafficScript rules with generic protocols and give some examples:

• How does TrafficScript Work?
• Rewriting responses with "Generic Client First" and "Generic Server First" protocols
• Virtual hosting FTP services
• ZXTM TrafficScript Manual