Request and Response Rules

In some circumstances, a poorly written request or response rule can stall a connection. If you call a function such as request.getLine(), the connection can block until it receives another line of input. If you've mis-parsed the connection and the client or server are not going to send any more input, the connection can stall indefinitely (until it is timed out).

Take great care to correctly parse a protocol if you write a detailed handler for it. Your implementation of the handler determines precisely how the protocol is handled. When developing such a handler, several techniques are useful:

•Use log.info() to emit verbose debugging information, for example, when each rule starts and when it ends.

•Use a system call tracer such as strace or truss to monitor exactly what data is being read and written to the network.

The script ZEUSHOME/zxtm/bin/trace can assist with this. Type trace –-help for more information.

•Use tcpdump or wireshark to monitor what the client and server is sending, but be aware that if a rule is blocked reading from the client, it does not notice that the server has sent any data.

Use the Activity > Connections page in the Admin UI to monitor the connections and individual requests being handled by the Traffic Manager. This data can be further enhanced with the Traffic Manager’s Request Tracing capability. With this feature enabled, use the Connections page to provide detailed information about the time-line for each connection. This can be particularly useful by showing if a connection is being stalled when running a TrafficScript rule. Refer to the Pulse Secure Virtual Traffic Manager: User’s Guide for more information on this feature.