Respond to server depending on TCP::client_port

Wow... that's a novel concept for serially broadcasting a request to all pool members. So for a single client connection, you send the request to each pool member. Periodically, servers will send a watchdog packet to the client and you need to know how to handle that based on whether the client has "silently disappeared" or not. It sounds like in order to test the client status, you'd need to either generate your own packet to the client or pass the server's request through. I'd guess the latter would be simpler.

 

 

So is the issue that you need to track which server generated the watchdog request when you get the client response to that watchdog request? If I am following you...

 

 

Does the Diameter protocol have a way to insert an arbitrary field in a request which the client will return in the response? If so you could insert a session ID there. Or can you use the Origin-State-Id in the message to track which server generated the original watchdog request with a sesison table entry which maps the Origin-State-ID to a specific server?

 

 

Also, out of curiosity, what are you using TCP::notify response for? I've only seen references to it for triggering the USER_REQUEST/RESPONSE events, but I don't see either event in your rule.

 

 

Aaron