Calling connect when you are already connected it may throw an exception but I don't think it matters. You could try putting a TCP.Client.Disconnect before each TCP.Client.Connect but this is not very elegant. It might work...
Yes the receiver will disconnect and the TCP libraries in .Net are terrible about not noticing that the connection has been closed by the remote server. It can take a really long time to notice and may not even notice unless you are sending commands, even when sending command it will put them on a stack or in a buffer or something and act like everything is peachy and still take a while to start throwing errors! Perhaps when we move to .Net 4 there will be something better we can use. With my iTach I can open a connection and it stays open reliably unless the network is unplugged or my computer goes to sleep. When the computer wakes up I do a little thing to reinitialize the connection.
But now that you've got your commands and your terminator done correctly for both sending and receiving you can try the following.
First of all, for just sending commands that don't require feedback, I suggest using TCP.single. I suspect that this will work reliably, and it is a lot less work for VC, but it might not work all the time if iRule is on and actively trying to keep the connection open.
For commands that require feedback (for now anyway) you have a few options.
Option A.
1 - Create a client using TCP.Client.Connect, send the command(s), don't do anything else in this command
2 - when the feedback event is fired process the feedback from the event payload, and then disconnect the client.
This should all happen almost instantly unless your receiver is very slow to respond for some reason. The only problem here is that if the event does not come back from some reason the client will remain connected, or at least think that it is... But you can try it and see if it is reliable now that you are using the terminator correctly.
Option B.
1 - Create a client using TCP.Client.Connect, send the command(s), and then trigger an event by using VC.SetEventTimer. Use any eventName you want but assign that event to a command that disconnects from the client. Experiment to see how long the amp takes to trigger the other event and then try to set the shortest timer delay that will safely let the receiver respond in time.
2 - the feedback event will fire as above but you don't disconnect the client here
3 - the disconnect event will fire next and you can disconnect the client in the command that is triggered.
This should probably work reliably (as long as irule doesn't interfere) but be careful if you have multiple commands going simultaneously that they don't overrun each other where one tries to connect before the other closes (well maybe it will still work...)
Option C. is basically what you were doing before but with the connect terminators and a few minor adjustments.
1 - open the client, send the commands, pause (only for a short time), then disconnect.
This might not work because VC.Pause blocks the main thread of VC and may prevent the TCP stuff from executing. Try it and if it doesn't work change the name of the command so that it starts with ++ This is a trick to run the command in it's own thread. Each of the actions in the command will actually be executed on the main thread, but not the containing macro or the VC.Pause actions. Other actions will be "invoked" or "injected" into the main thread... blech... threading... Anyway, it can be very helpful sometimes but only use the ++ trick when you need it!
Finally, if it turns out that all this works well but only when iRule is NOT running, and iRule starts to interfere then you have to find another solution and you can't blame the problem on VC. If your VC machine is on all the time, then you could probably set it up to relay command from iRule to the receiver without toooooo much trouble
