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.

How do they work?

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

• 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.

• 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.

• 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 server-first connection. In addition, ZXTM slurps and discards the first line or data (terminated by a \n) that the server sends.

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

Owen Garrett [Zeus Dev Team] 05 March 2007