Forum Discussion

beefy80's avatar
beefy80
Icon for Nimbostratus rankNimbostratus
Oct 01, 2014

Multiple Transaction Handling

Hello

 

I am working on a project to handle requests from our customers. These request are in the form of short transactions. Most customers make a TCP connection into us the request is sent and we respond with an Answer the customer closes the TCP connection. Some customers however open a TCP connection and leave this connected and while this is connected they can send multiple transactions (either one after the other or multiples at a time).

 

The iRule that I am planning to deploy (and failed at) will take the payload received from the customer and depending on a flag in this payload will send the transaction to one of two pools. We also take some data from the payload and send this using HSL to syslog for analytic's.

 

The iRule falls over when a customer that keeps the connection open sends in more than one request at a time. The problems experienced are: 1. The request response have no unique tag available so it can get jumbled up from a logging point of view 2. When a response is received back the irule calls LB:detach (this was added to stop these customers that leave the session open from having a constant connection to the application) once we receive a response back. If two requests are made at the same time the LB:detach breaks the response from the second request. 3. As a LB member has been selected the multiple requests are sent to this where ideally the load would be split across the members.

 

I guess I need to know if there is a way to handle multiple sessions within an iRule that are coming over the same tcp session. I have looked at using Table or tracking with Var's but would like to know if anyone has any advise on how to achieve this.

 

Thanks

 

James

 

2 Replies

  • I'm sure there's something we can do. Does each request represent a single packet? Are they a certain size? I'm sure we can also tie a response to a request. Can you provide some detail on what a request looks like please?

     

    Also, you can avoid the use of LB::detach by implementing OneConnect.

     

  • Only one request packet is received from the client that forms a transaction this is wrapped in STX and ETX (My iRule expects to see ETX before it TCP::releases) while the transaction is processing we respond with status messages these are short messages that start $...... (there can be a couple of these depending on how the system is performing) and finally there is a full response. Currently at this point a LB::detach will be called but that will break any other transactions that may be processing.

     

    I have been reading about the OneConnect Profile and not sure if this will work but I am all ears.

     

    James