 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
VB Forum / COM / April 2005Help Needed on ActiveX EXE winsock worker
Hi, I am trying to create a ActiveX EXE that wrap the Winsock API functions. In my standard EXE, there is a Server socket listening for client connection. Once there is a connection request, the standard EXE will create new instances of the ActiveX EXE and use the socket in the ActiveX EXE to connect to the client. I am using CSocketMaster winsock API class in my ActiveX EXE. When I call the CSocketMaster.Accept and pass the requestID from standard EXE, I got this error saying "Scket operation on nonsocket". Is it illegal to pass the requestID from standard EXE to ActiveX EXE? How could I overcome this problem? Thanks for any help. J. > Is it illegal to pass the requestID from standard EXE to ActiveX EXE? At least for the Winsock.OCX it's illegal, to pass the requestID across ThreadBoundaries. > How could I overcome this problem? You should use the WinSock-Accept-API directly (on the socket-handles, not on some IDs) - that will work Cross-Thread. Olaf > > Is it illegal to pass the requestID from standard EXE to ActiveX EXE? > At least for the Winsock.OCX it's illegal, to pass the requestID across [quoted text clipped - 5 lines] > > Olaf Thanks for the prompt reply. However, it would be of great help if you could elaborate more or even better if you could provide few lines of sample code on it. Sorry I am not too good in the API, I am using the CSocketMaster class (Winsock API wrapper) which was downloaded from Web, without any modification on it. Thanks. J. > However, it would be of great help if you could elaborate more > or even better if you could provide few lines of sample code on it. I've looked at the Class you mentioned - it's not possible with a few lines of code, to make this work in a multithreaded AX-Exe-Environment. But if you want to make a stable, multithreaded server wich is getting jobs over different client-sockets, your workers don't have to contain the transport-layer (the sockets). Simply let the listening serversocket and all the clientsockets in the main-thread, isolate the jobs from the incoming socket-requests, pass the job-data to your worker-threads, async start the jobs inside the workers and pass the results back to the main-thread to send them back over the right client-socket. Olaf > I've looked at the Class you mentioned - it's not possible with a few lines > of code, to make this work in a multithreaded AX-Exe-Environment. [quoted text clipped - 7 lines] > > Olaf Thanks again for your reply. Well, actually the app that I am doing is kind of message distributor, with a server listening for connection (could be 10, 20, or even more). Whenever there is a message received from one of the client app, this server app is then resposible to distribute the message to the respective recepient modules (could be 1, 2 or more). My current design is to have a buffer storing incoming message, and a timer where the distributing of the message take place. In the timer event, the server would then get the message out from the buffer and send it to respective client modules, without any heavy processing on the message. In this case the sending of message to the recepient module is in sequence, making it possibly delay if there is many receipient modules for the particular message. The problem would become more obvious if I were to put in the message acknowledgement, timeout and resend (this is needed to solve the incapability of the server app to detect the network problem at client). So what I can think of to oversome this possible problem is to create a worker thread which the server can just simply pass the message to it without worrying about the message acknowledgement etc. So each worker thread should then have their own buffer to store the incoming message, and send it out one by one. By this, I think the idea that you have suggested would not applicable here. Any advice? J. > By this, I think the idea that you have suggested would not > applicable here. Any advice? Workers in a multithreaded environment are needed, to handle blocking, timeconsuming jobs. Since your reasons for blocking are socket-send-problems, it's not the worst idea, to put them into threads. You wouldn't have a problem with that (App could stay singlethreaded), if your socket-class would be capable, to send Buffers out async and detect receive-problems at the client instantly. There are socket implementations, wich are capable of those things. Your's is not. So you can either stay singlethreaded and enhance to async socket-send capabilities (implement it yourself per WriteFile or WsaSend-APIs or use another socket-implementation wich is capale of that) - or work with threads (pass the content and the sockethandle of an accepted socket and use the modified SendBufferedDataTCP-function of your socket-class inside the worker). Olaf |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.