To be sure that the response (method result) generated by the server is expected (yet) by a method call not timed-out.

We are using this library in some projects, it's great. Thank you!

With this check we try to avoid that a method call gets as result the response really associated with a previous call that fisnished with a timeout.

The sequence that this code avoid:
1) A method call ends with timeout. The responseID associated is 1, and when the server finally returns the result this will be stored in the responseTable attribute.
2) 62 method calls come then without problems.
3) The next method call (with responseID = 1) will send the invokation via TCP and then it will wait the server response. As responseTable has a result for responseID=1 the last method call gets as result the result associated with the timed-out call :-(

I know that the solution that I propose is not perfect, but at least we can keep 63 parallel calls. I thought to use an UUID per method call, to identified it absolutly, but it would be slower than this solution.

What do you think? Do I forget something? Am I doing something wrong?