About the parallel processing of iRules

Thank you for the answer.

 

 

However, the thing which I would like to do is just this.

 

"wait for the application server to decide for each request at request time and wait for that answer."

However, the thing which I would like to do is just this.

 

"wait for the application server to decide for each request at request time and wait for that answer."

 

 

 

If that's really really what you want to do, then I can see two approaches. Both of them will very likely require some work on your part to make your verification server function in a way that's compatible with the solution.

 

 

The first approach is to use HTTP::retry. The way to do that is to have all requests go to a verification server pool by default, then check their result in HTTP_RESPONSE, and then use HTTP::retry to send the request to the real application pool (or not, depending on the result from the verification server).

 

 

The second approach is to use the DNS or AUTH functionality. The way to do that is to use HTTP::collect without a length parameter to buffer the entire client request, then send whatever data the verification server needs via a DNS request or authentication request, and wait for the verification GO/NO-GO decision via the NAME_RESOLVED or AUTH_RESULT events.

 

 

Like I said above, you'll need to make one of these approaches compatible with your verification server. One way to do this is to create some server which will listen for these HTTP, DNS, or authentication requests, translate them into some form appropriate for your verification server, send them, and translate the responses back for the BIG-IP system in some way to make the GO/NO-GO decision (for example, if you go the HTTP route, a 200 response could be GO, and a 404 response could be NO-GO).

 

Thank you for the answer.

 

 

Although I would like to treat not only HTTP but FTP, SIP, etc., am I possible by the above-mentioned method?

 

For a general TCP solution, you'll have to use the second approach I talked about (DNS or authentication). You'll just do a "TCP::collect 1048576" in CLIENT_ACCEPTED (as well as your DNS or authentication request to your verification server), then to a TCP::release in the NAME_RESOLVED or AUTH_RESULT event.

 

 

The corner case here is where the client sends more than 1048576 bytes (1 megabyte) of data before you get the response from your verification server. In that case, the CLIENT_DATA event will fire. You can use a variable to track if NAME_RESOLVED or AUTH_RESULT fired before CLIENT_DATA, so you can at least detect this corner case. You'll have to decide how to handle it, though.