Collect and process new payload from same TCP session

but the remote app sends in another data payload to be processed just the same but maintaining the TCP session, is it possible?you mean to load balance one clientside tcp connection to different pool member based on payload, don't you?

 

 

is it similar to this thread?

 

 

Dispatch messages from a single connection to pool members

 

https://devcentral.f5.com/Community/GroupDetails/tabid/1082223/aft/2163630/asg/50/Default.aspx

Hi Nitass,

 

 

 

Yes, from the dispatch thread, i think its somewhat similar though mine selects between 2 pools based on the payload content match. i'll try to replicate the irule you had created particularly using tcp::notify on my irule and see if it works. i will let you know. thanks

 

 

 

lez

Hi Nitass,

 

 

 

just attempted to test but im having the error below. I made some random tests adding LB::detach, tcp::close, return...but to no avail. I can see it already started to read the second payload which should be the last but seems it cannot forward to the correct pool as there's already an existing connection. Any thoughts?

 

 

Nov 5 21:20:40 local/tmm info tmm[5266]: Rule test_tx_irule5 : Payload is 186

 

Nov 5 21:20:40 local/tmm info tmm[5266]: Rule test_tx_irule5 : PAYLOAD Matched 000000

 

Nov 5 21:20:40 local/tmm info tmm[5266]: Rule test_tx_irule5 : PAYLOAD 000000 goes to Pool 2

 

Nov 5 21:20:53 local/tmm info tmm[5266]: Rule test_tx_irule5 : Payload is 314

 

Nov 5 21:20:53 local/tmm info tmm[5266]: Rule test_tx_irule5 : PAYLOAD Matched 000001

 

Nov 5 21:20:53 local/tmm info tmm[5266]: Rule test_tx_irule5 : PAYLOAD 000001 goes to Pool 1

 

Nov 5 21:20:53 local/tmm info tmm[5266]: Rule test_tx_irule5 : 000001

 

Nov 5 21:20:53 local/tmm err tmm[5266]: 01220001:3: TCL error: test_irule5 - Address in use (line 1) i nvoked from within "pool Pool1"

 

 

 

 

when CLIENT_ACCEPTED {

 

TCP::collect

 

}

 

 

when CLIENT_DATA {

 

 

use pool2 by default

 

pool Pool1

 

 

set mero [TCP::payload]

 

log local0. $mero

 

Start reading at the 5th byte and save 6 characters to $match

 

if {[binary scan $mero x5a6 match] == 1}{

 

log local0. "Matched $match"

 

if { $match eq "000001" } {

 

log local0. "PAYLOAD $match goes to Pool 1"

 

log local0. $match

 

pool Pool1

 

} else {

 

log local0. "PAYLOAD $match goes to Pool 2 "

 

pool Pool2

 

}

 

 

}

 

TCP::release

 

TCP::notify request

 

TCP::collect

 

}

 

 

 

Many thanks,

 

 

lez

Lez,

 

 

The log output suggests the error is being generated by a different iRule!

 

 

Nov 5 21:20:53 local/tmm info tmm[5266]: Rule test_tx_irule5 : 000001

 

Nov 5 21:20:53 local/tmm err tmm[5266]: 01220001:3: TCL error: test_irule5 - Address in use (line 1) i nvoked from within "pool Pool1"

Hi Steve,

 

 

 

Sorry, mixed my irule logs, may have copied the ones up the scroll, i made different irules as i try adding other stuff that i know of to attempt to somewhat make the next payload a new session, but anyway, the last 3 or so attempts, i had same output, "address in use (line 1)". I have read from other posts that such message is a bug in 11.x but im using 10.2, any ideas on this? Thanks.

 

 

 

Lez

I'm no iRules expert but can I recommend a few things;

 

 

1) Remove any persistence profile associated with the VS

 

2) Use OneConnect with the VS

 

3) Use the LB:detach command just before each Pool command

Hi Guys,

 

 

 

 

Just an update, below irule seems to have done what i need, though more tests to confirm, thanks Nitass and Steve (option 3 worked)...

 

 

 

when CLIENT_ACCEPTED {

 

TCP::collect

 

}

 

 

when CLIENT_DATA {

 

set mero [TCP::payload 11]

 

Start reading at the 5th byte and save 6 characters to $match

 

if {[binary scan $mero x5a6 match] == 1}{

 

log local0. "PAYLOAD Matched $match"

 

if { $match eq "000001" } {

 

log local0. "PAYLOAD $match goes to Pool 1"

 

log local0. $match

 

LB::detach

 

pool Pool1

 

log local0. "Finished choosing POOL 1"

 

TCP::release

 

 

 

} else {

 

log local0. "PAYLOAD $match goes to Pool 2 "

 

LB::detach

 

pool Pool2

 

log local0. "Finished choosing POOL 2"

 

TCP::release

 

}

 

}

 

 

TCP::release

 

TCP::notify request

 

TCP::collect

 

}

 

Glad to hear it. Let us know if the testing isn't successful.

Hello everyone,

 

 

I´m trying to resolve a similar situation where a LB decision is made when a match is founded on payload data. I´m using practically the same iRule structure as Lez example, however it works only the first time the payload is sent. Once the LB decision is made, all the next payload data is delivered to the same elected pool, it means that the match is made only the first payload is received and the following is only forwarded.

 

This is a simple TCP connection ( no HTTP), a Client-Server permanent session, where I received transactions.

 

 

I followed the steps recommended by Steve as well.

 

 

1) Remove any persistence profile associated with the VS

 

2) Use OneConnect with the VS

 

3) Use the LB:detach command just before each Pool command

 

 

Please HELP!!!!!

IT WORKSSSSSS.....I found the issue. I was missing the last configuration part for the iRule that includes the following lines:

 

 

TCP::notify request

 

TCP::collect

 

 

Regards......

 

 

CALVILLO