Connecting Multiple clients to single server using DCOM
-
Hi all Can i have examples on Multipleclients connected to a single server using DCOM Thanks in advance abhi
-
Hi all Can i have examples on Multipleclients connected to a single server using DCOM Thanks in advance abhi
I cannot give you an example, but I can tell you how to set one up for yourself, assuming that you have some knowledge of COM. If you have any problems with these suggestions, that you will need to consult the help documentation, or post a simple question. Before I start, I would like to say that operation of DCOM is much the same as the operation of COM. If you get the server and clients to work together on the same computer, then all you need to do is to change a few calls, and make sure that the security privileges are set, and then everything should work. Unfortunately, security is not a trivial matter, and you will probably have to study it for yourself, in order to get everything working. Firstly create a com out-of-process exe server, with your desired remote interface included. Secondly create a client application that is able to use the above created server interface on your local computer. Use CoCreateInstanceEx() to create the instance of the interface, setting the "ServerComputerName" to your local computer name eg:
COSERVERINFO csi = {0}; csi.pwszName = L"ServerComputerName" csi.pAuthInfo = NULL; MULTI_QI qi[1] = {0}; qi[0].pIID = &IID_IMyInterface if ( SUCCEEDED( CoCreateInstanceEx(CLSID_MyInterface, NULL, CLSCTX_REMOTE_SERVER, &csi, 1, qi ) ) { CMyInterface *pMyInterface = static_cast( qi[0].pItf); // Use the created pMyInterface and release it if no longer needed }Test it to make sure your server interface works as anticipated. When it does, you can replace ServerComputerName with the actual intended server. Security is the number one headache when programming DCOM. Inserte calls to CoInitializeSecurity() in the server and client InitInstance() like this:CoInitializeSecurity(NULL, -1, NULL, NULL, RPC_C_AUTHN_LEVEL_NONE,RPC_C_IMP_LEVEL_IMPERSONATE, NULL, EOAC_NONE, NULL);which will reduce the security checking. Install the server onto another computer by registering it and running it. Use DCOMCNFG to check that permissions have been set so that remote users have access to your server program. You may also need to set the COM default limits. You should be able read up on using DCOMCNFG in any good COM documentation. Finally on XP etc, check that the firewall will allow this program to allow/have access to remote users. You may also need to set the firewall on the client computer to allow your computer program to connect out. If all the steps have been followed successfully, then you shoul -
I cannot give you an example, but I can tell you how to set one up for yourself, assuming that you have some knowledge of COM. If you have any problems with these suggestions, that you will need to consult the help documentation, or post a simple question. Before I start, I would like to say that operation of DCOM is much the same as the operation of COM. If you get the server and clients to work together on the same computer, then all you need to do is to change a few calls, and make sure that the security privileges are set, and then everything should work. Unfortunately, security is not a trivial matter, and you will probably have to study it for yourself, in order to get everything working. Firstly create a com out-of-process exe server, with your desired remote interface included. Secondly create a client application that is able to use the above created server interface on your local computer. Use CoCreateInstanceEx() to create the instance of the interface, setting the "ServerComputerName" to your local computer name eg:
COSERVERINFO csi = {0}; csi.pwszName = L"ServerComputerName" csi.pAuthInfo = NULL; MULTI_QI qi[1] = {0}; qi[0].pIID = &IID_IMyInterface if ( SUCCEEDED( CoCreateInstanceEx(CLSID_MyInterface, NULL, CLSCTX_REMOTE_SERVER, &csi, 1, qi ) ) { CMyInterface *pMyInterface = static_cast( qi[0].pItf); // Use the created pMyInterface and release it if no longer needed }Test it to make sure your server interface works as anticipated. When it does, you can replace ServerComputerName with the actual intended server. Security is the number one headache when programming DCOM. Inserte calls to CoInitializeSecurity() in the server and client InitInstance() like this:CoInitializeSecurity(NULL, -1, NULL, NULL, RPC_C_AUTHN_LEVEL_NONE,RPC_C_IMP_LEVEL_IMPERSONATE, NULL, EOAC_NONE, NULL);which will reduce the security checking. Install the server onto another computer by registering it and running it. Use DCOMCNFG to check that permissions have been set so that remote users have access to your server program. You may also need to set the COM default limits. You should be able read up on using DCOMCNFG in any good COM documentation. Finally on XP etc, check that the firewall will allow this program to allow/have access to remote users. You may also need to set the firewall on the client computer to allow your computer program to connect out. If all the steps have been followed successfully, then you shoulThanks I will try using your inputs. abhi
-
I cannot give you an example, but I can tell you how to set one up for yourself, assuming that you have some knowledge of COM. If you have any problems with these suggestions, that you will need to consult the help documentation, or post a simple question. Before I start, I would like to say that operation of DCOM is much the same as the operation of COM. If you get the server and clients to work together on the same computer, then all you need to do is to change a few calls, and make sure that the security privileges are set, and then everything should work. Unfortunately, security is not a trivial matter, and you will probably have to study it for yourself, in order to get everything working. Firstly create a com out-of-process exe server, with your desired remote interface included. Secondly create a client application that is able to use the above created server interface on your local computer. Use CoCreateInstanceEx() to create the instance of the interface, setting the "ServerComputerName" to your local computer name eg:
COSERVERINFO csi = {0}; csi.pwszName = L"ServerComputerName" csi.pAuthInfo = NULL; MULTI_QI qi[1] = {0}; qi[0].pIID = &IID_IMyInterface if ( SUCCEEDED( CoCreateInstanceEx(CLSID_MyInterface, NULL, CLSCTX_REMOTE_SERVER, &csi, 1, qi ) ) { CMyInterface *pMyInterface = static_cast( qi[0].pItf); // Use the created pMyInterface and release it if no longer needed }Test it to make sure your server interface works as anticipated. When it does, you can replace ServerComputerName with the actual intended server. Security is the number one headache when programming DCOM. Inserte calls to CoInitializeSecurity() in the server and client InitInstance() like this:CoInitializeSecurity(NULL, -1, NULL, NULL, RPC_C_AUTHN_LEVEL_NONE,RPC_C_IMP_LEVEL_IMPERSONATE, NULL, EOAC_NONE, NULL);which will reduce the security checking. Install the server onto another computer by registering it and running it. Use DCOMCNFG to check that permissions have been set so that remote users have access to your server program. You may also need to set the COM default limits. You should be able read up on using DCOMCNFG in any good COM documentation. Finally on XP etc, check that the firewall will allow this program to allow/have access to remote users. You may also need to set the firewall on the client computer to allow your computer program to connect out. If all the steps have been followed successfully, then you shoulhi iam working on a single computer. What i have done is , i have designed a GUI in server containg a multiline edit box. and whenever iam executing client application clients message is capturing in the edit box of server GUI. And what iam trying to do is whenever multiple clients are executed clients messages should be captured in the editbox of server GUI. But the problem is whenever iam executing a client a new server application is executing and message is captured in the GUI of that server. But what i want is all client should communicate to a single serverand messages should be captured in that Servers GUI. I think you understood my problen . can u please help me on this. Thank You abhi
-
hi iam working on a single computer. What i have done is , i have designed a GUI in server containg a multiline edit box. and whenever iam executing client application clients message is capturing in the edit box of server GUI. And what iam trying to do is whenever multiple clients are executed clients messages should be captured in the editbox of server GUI. But the problem is whenever iam executing a client a new server application is executing and message is captured in the GUI of that server. But what i want is all client should communicate to a single serverand messages should be captured in that Servers GUI. I think you understood my problen . can u please help me on this. Thank You abhi
The most important thing to check is the InitInstance of the server app. The function _Module.RegisterClassObjects() is called to setup the class factory. For the multiple user situation that you need it is important that the parameter REGCLS_SINGLEUSE is not used. Make sure that a line similar to this is applied:
_Module.RegisterClassObjects(CLSCTX_LOCAL_SERVER, REGCLS_MULTIPLEUSE )(NB In vc7.1, the object might be _AtlModule) Make sure that the server is running before you use the client. Assuming that that messages can be posted to your edit box from anywhere in your server app, you can send a message from the constructor of your interface class to show that the interface has been created from the running instance of your server. If this does not work, or is not applicable then please let me know. -
The most important thing to check is the InitInstance of the server app. The function _Module.RegisterClassObjects() is called to setup the class factory. For the multiple user situation that you need it is important that the parameter REGCLS_SINGLEUSE is not used. Make sure that a line similar to this is applied:
_Module.RegisterClassObjects(CLSCTX_LOCAL_SERVER, REGCLS_MULTIPLEUSE )(NB In vc7.1, the object might be _AtlModule) Make sure that the server is running before you use the client. Assuming that that messages can be posted to your edit box from anywhere in your server app, you can send a message from the constructor of your interface class to show that the interface has been created from the running instance of your server. If this does not work, or is not applicable then please let me know.Its working fine Thankyou very much. abhi
-
The most important thing to check is the InitInstance of the server app. The function _Module.RegisterClassObjects() is called to setup the class factory. For the multiple user situation that you need it is important that the parameter REGCLS_SINGLEUSE is not used. Make sure that a line similar to this is applied:
_Module.RegisterClassObjects(CLSCTX_LOCAL_SERVER, REGCLS_MULTIPLEUSE )(NB In vc7.1, the object might be _AtlModule) Make sure that the server is running before you use the client. Assuming that that messages can be posted to your edit box from anywhere in your server app, you can send a message from the constructor of your interface class to show that the interface has been created from the running instance of your server. If this does not work, or is not applicable then please let me know.hi what iam tring to do is iam trying to create tool that closely resembles the working of DbgView . The way the DbgView tool works is: You can launch the tool on the system. OutputDebugString() is a Win32 API. If you use that API in your program, the output will then be shown on DbgView. SO using this functionality i want to use OutputDebugString() in my applications and i want the output(string in OutputDebugString()) to be shown in servers GUI. CAn u suggest me how to proceed. Thanks in Advance abhi
-
hi what iam tring to do is iam trying to create tool that closely resembles the working of DbgView . The way the DbgView tool works is: You can launch the tool on the system. OutputDebugString() is a Win32 API. If you use that API in your program, the output will then be shown on DbgView. SO using this functionality i want to use OutputDebugString() in my applications and i want the output(string in OutputDebugString()) to be shown in servers GUI. CAn u suggest me how to proceed. Thanks in Advance abhi
How many applications do you have that need to send output to the server GUI? If the answer is just one or two, then you could just write a short function to create the COM interface object on the remote server, use it, and then release the interface. The downside of doing this would be that several round trips between the client and server computers would be necessary, resulting in time delays, plus you would need to deal with the security issues in all the client programs, and of course the server. What sort of scale are we discussing here? How many messages would need to be sent. Would you need to keep the interface open during the total life of the client program, or could it open just when sending messages to the server? If you wanted to recreate the com interface every time that you wish to send a message, you could write some code like this (using MFC CStrings, but these could be replaced with other types):
int PrintToServerGUI( LPCTSTR szFormat, ... ) { int nTextLen = 0; if ( szFormat ) { CString strOut; va_list p_arg; va_start( p_arg, szFormat ); strOut.FormatV( szFormat, p_arg ); nTextLen = strOut.GetLength(); va_end( p_arg ); } int nWritten = 0; if ( nTextLen > 0 ) { // Create interface to my server GUI IMyServerGUI *pMyServer = NULL; ... // Code for creating interface using CoCreateInstanceEx() eg ... // hr = CoCreateInstanceEx(CLSID_MyServer, NULL, CLSCTX_REMOTE_SERVER, &csi, 1, qi ); ... // pMyServer = static_cast<IMyServerGUI *>(qi[0].pItf); ... if ( pMyServer ) { if ( SUCCEEDED( pMyServer->OutputString( strOut ) ) ) { nWritten = nTextLen; } pMyServer->Release(); } } return nTextLen; }You need to write your own interface creation code for your com interface. Note that is code assumes that you have a function in your interface called OutputString( LPCTSTR pString ). If there are a lot of applications that need to communicate with the server, then it may be better to use an intermediate server programming on the local client, that would then pass the messages as appropriate to the server program. The advantage would be that in network security terms, you would only need to concern yourself with the traffic between the server and intermediate server. -
How many applications do you have that need to send output to the server GUI? If the answer is just one or two, then you could just write a short function to create the COM interface object on the remote server, use it, and then release the interface. The downside of doing this would be that several round trips between the client and server computers would be necessary, resulting in time delays, plus you would need to deal with the security issues in all the client programs, and of course the server. What sort of scale are we discussing here? How many messages would need to be sent. Would you need to keep the interface open during the total life of the client program, or could it open just when sending messages to the server? If you wanted to recreate the com interface every time that you wish to send a message, you could write some code like this (using MFC CStrings, but these could be replaced with other types):
int PrintToServerGUI( LPCTSTR szFormat, ... ) { int nTextLen = 0; if ( szFormat ) { CString strOut; va_list p_arg; va_start( p_arg, szFormat ); strOut.FormatV( szFormat, p_arg ); nTextLen = strOut.GetLength(); va_end( p_arg ); } int nWritten = 0; if ( nTextLen > 0 ) { // Create interface to my server GUI IMyServerGUI *pMyServer = NULL; ... // Code for creating interface using CoCreateInstanceEx() eg ... // hr = CoCreateInstanceEx(CLSID_MyServer, NULL, CLSCTX_REMOTE_SERVER, &csi, 1, qi ); ... // pMyServer = static_cast<IMyServerGUI *>(qi[0].pItf); ... if ( pMyServer ) { if ( SUCCEEDED( pMyServer->OutputString( strOut ) ) ) { nWritten = nTextLen; } pMyServer->Release(); } } return nTextLen; }You need to write your own interface creation code for your com interface. Note that is code assumes that you have a function in your interface called OutputString( LPCTSTR pString ). If there are a lot of applications that need to communicate with the server, then it may be better to use an intermediate server programming on the local client, that would then pass the messages as appropriate to the server program. The advantage would be that in network security terms, you would only need to concern yourself with the traffic between the server and intermediate server.Thanks for your suggestions. now instead of server capturing client messages now i want client's Gui capture messages from serevr. how to proceed further with this. thanks in advance abhi
-
Thanks for your suggestions. now instead of server capturing client messages now i want client's Gui capture messages from serevr. how to proceed further with this. thanks in advance abhi
Please could you clarify exactly what you are requesting. i.e. Are you looking to receieve messages on your client? Is this the same client as the previous client? If the client is the same program, then the usual way to allow the server to call the client by using an event sink, which you can search for and read about on CodeProject, and most books on COM. This generally works very well, but the security issues can be a real pain to overcome. I cannot say any more than this at this stage without knowing more details.