At least for me.
That makes sense after thinking a bit. Lets see if I got that right: WSASend needs to have direct access to the LPWSABUF pointer so it can increment the pointer through the multiple WSABUFs and send several buffers on a single call. Hence, give it the address of that guy.
Regarding the strange line: m_overlapped[ *mp_send_array_index ],
The main app creates and owns the buffers to output to a client via TCP/IP. It creates a structure to hold the pointers to the buffers. The pointer to the buffers are in an array of WSABUF and there are two integers, load_array_index and send_array_index. Main app uses the load_index to keep track of which WSABUF item to use next and C_TCP_API_Server (presented momentarily) uses send_index to keep track of which one to send next.
The class to manage the TCP/IP operations is C_Server_Thread and is started as a thread from main_app and the structure is passed via the one pointer.
That C_Server_Thread has events to trigger/control it and other performance monitoring variables. It creates class C_TCP_API_Server to manage the details of the TCP/IP. That class needs only a subset of the structure passed. So C_Server_Thread hands off a pointer to the index values.
Hence, the pointer to the index and the * dereference character.
Elsewhere: C_TCP_API_Server created its own thread, a completion thread. It collects the events from the I/O completion, a unique event assigned to each item in the array of buffers. It gets the event and simply NULLs the address and zeroes the length value in the WSABUF, and everyone knows that buffer is ready to be used again.
It is a bit complicated but the end application will handle a stream of 12 megabits/second and must extract parameters real time and pass them on. Some of those parameters are bit wise meaning a 16 bit word will have 16 parameters, each of which must be separated and given its own name. (Actually a tag number, which is a direct reference to the name.) Then the parameters are passed on to a display system. There will be up to four copies of this app running at one time because as many as four of these telemetry transmitters may be active at one time. It must be fast and efficient to display the data in real time. (Ok, to be very technical, very near real time) Safety must be able to see many of these parameters and have the ability to destroy it if things go badly. I have an early version of the app running but it uses blocking TCP which is can be a real pain. This app interfaces with another system and if it gets killed, those interface slots are not released causing major problems. Not counting the bit wise parameters, there can be close to 10,000 individual parameters that must each be recognized and extracted. Quite a mess but the unit under test is rather complicated and expensive. The engineers want all the data they can get.
Right now main_app is purely a test vehicle to check out these TCP server classes. So far, I have written code to test all the events to C_Server_Thread, and have successful tested the completion events. I am able to trigger and detect all the events to C_Server_Thread and all the completion events. I have code to show the addresses of all the buffer and that looks good. The test data is initialized with unique values and I am tracking it at each step of the way.
This is my first foray into the world of using the APIs to implement TCP/IP control, and of using threads. It has been the most difficult code I have written, but I am happy with my progress, ..., so far.
There is no way I could have progressed this far without help from these forums and specifically from you.
Thank for so much for your time and mostly for your patience.
Thank you for your time
If you work with telemetry, please check this bulletin board: www.irigbb.com
modified 14-Aug-14 9:37am.