Hi,
I downloaded the project code (CommandPattern.zip) associated with this article describing a "server/client" model using RTI --- The Command Pattern: Distributed RPC with QoS; since the project was somewhat "old", I needed to rerun "rtiddsgen" and feather in the changes appropriately. I rebuilt the Visual Studio "console" project (client & server sides) & was able to run the simple server/client test in the code - output provided in console windows.
I next ported the code to live in a "Windows" project - the initialization code is the same with the major difference of replacing an infinite loop with the Windows message pump loop ..
... "Server" code snippet was ---
DDS_Duration_t span = {1,0};
...
while(1)
{
NDDSUtility::sleep(span);
}
---- is being replaced by this ...
// Main message loop:
while (GetMessage(&msg, NULL, 0, 0))
{
if (!TranslateAccelerator(msg.hwnd, hAccelTable, &msg))
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
}
The server's incoming detection from the client request is not being "seen" -- I suspect the message pump is prohhibiting the listener "callback". When I remove the message pump code & put back in the infinite time delay, I then see incoming client requests as before.
Any ideas?
thx, Rich..
I found the problem --- all the 'RTI' related threads were improperly exiting due to a software bug introduced when porting to (MFC) Windows. The "Command Server" class instance is a stack variable in a nested function - it was destroyed (by mistake) when returning from that function. A little code re-org solved it -- interesting experiment showed that two independant communication 'engines' (each defined in its own .IDL) could run together without collision. I'm wasn't sure about the best RTI strategy here; I initially thought a single "merged" ".IDL" file was required.