Hi,
I've recently encountered what I believe to be an issue with the implementation of the UVSC API associated with Application Note 198.
The API is supposed to allow up to 10 concurrent connections to uVision instances but after debugging issues I had while trying to communicate with multiple uVision instances simultaneously from within the same process, it seems that the receive logic for UVSC's internal connection object is bugged.
The problem I believe I found is this:
-Each connection object has its own thread that it uses to call 'select' and 'recv' on the connection socket for the underlying Uvsock API. So far so good.
-The connection object tries to read the length field for a Uvsock message first so that it knows how long the corresponding message body is. It will then try and read the message body. No problem, seems standard.
-The member function responsible for reading the Uvsock message lengths and message bodies uses a set of global variables to keep track the state of consuming a single Uvsock message and also a global pointer to the the receive buffer within a connection object but the use of this pointer versus a direct reference to the current object's buffer is inconsistent within the function. Things are going wrong .....
-The actual bug: If you open two connections and the first connection consumes the length of a Uvsock message off its socket but not the body of the message before a second connection goes to consume the length of its next incoming message, the second connection's recv-member function will use the global pointer to the first connection object's receive buffer when calling recv to try and read its own length. Then the logic for decrementing the expected message length by the width of the length field will underflow the second connection's message length field (since it was just zeroed out and the length was written to the wrong buffer) and the second connection object now thinks that it needs to consume a Uvosck message of length 0xfffffffc (in the 32-bit verison of the API).
Is this product end of life or is there a chance this will be fixed? Why is the thin C/C++ wrapper around Uvsock closed source? If I posted this in the wrong place I apologize, I'm new here.