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 protocolsServer-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.
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 ProtocolsClient-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.
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
Once again, you can use TrafficScript rules to inspect the client's request data before making your load-balancing decision. Troubleshooting Protocol problemsTimeoutsAll 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. DeadlocksA request or response rule can cause the connection to block. For example, if ZXTM runs a request rule that calls ' 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 informationThe following articles describe how ZXTM processes TrafficScript rules with generic protocols and give some examples:
Owen Garrett
[Zeus Dev Team] 05 March 2007
|
Recently...
Other Resources
|




