Ok this is kind of an odd question but Im going to ask it because I need an answer
Lets say I have a server app that uses winsock I will call it server.exe and 2 people have client.exe which connects to server.exe, got me so far right?
ok now lets say there is a module in server.exe that does some extensive processing of some files when told to by client.exe
lets say client one sends a command to do the file processing which takes lets say 5 minutes to complete. In this routine it is looping to contstantly check the status of the job.
So before the job is finished, client two sends the same request which calls this module code. Does the code execute at the same time? or does it wait for the module code from client ones request to finish and then processes client twos request? or does it crash and cause a tear in the fabric of space/time?
I thought about using class modules because for each request you can create a new instance of the class which would then be running their own set of code within themselves, but the code in the module uses AddressOf when interfacing with this C++ DLL and you can only use AddressOf in a standard module.
Hahahaha...welcome to the world of multi clients and winsock servers
I bet your server has an array of winsock controls right?
This means that when client A is doing something, and the server is busy, client B is pretty much screwed. You can, if you want, process client B's request, but client A's request will be halted until client B's has finished
It's funny you should mention this as I am currently using winsocks which a multithreaded in my app
You're seen my multithreading code right?
Well I have have developed a new version which is easier to use and is more compact.
This combined with winsock allows you to create a generic multithreading winsock server manager.
This however is still mainly in development
When you start a server session you can pass in the name of a DLL, a class and the name of a function.
When the server received data from the client it uses createobject and callbyname to pass the data to your own custom dll which is relevant to your app.
Alas, my code is all broken and isn't very stable at the moment.
It will be about 1-2 weeks before I complete it.
The multi threading code is posted in the zip file. There are 2 demo projects.
1stly you MUST compile the vbGateway project.
Then for the simple example open and compile the Demo project, in the demo folder. Open 2 instances of the demo exe. Copy the hWnd from one into the child hwnd of the other, and vis versa. Now send messages between them,. I have added a lag of a few ms to demo the fact PostMessage works.
The 2nd demo is in the multithreading folde.r
Compile the ThreadUI project then the DemoUI project. Run the DemoUI exe.
This should demo the multithreading capability of VB
Now...there is a bug...and I don't know why. When posting data, every now and again the 1st few bytes of the data get corrupted Not sure why yet, but this isn't a major problem.
Anyways, once you have this up and running. What you can do, is change the style of app it is. Currently my multithreading demo searches for files. Why not change this so instead of searching for files it contains a winsock connection. This means each connection is in it's own thread. Thus you won't have the problems you are having.
Does all that make sense?
Like I said, I am currently working on a generic multithgreading winsock client and server DLL, that will handle all this automatically. But don't have code that I can distribute yet and it's hacks and crappy and uses my old method of multithreading, instead of my new compact 1 dll
Hope that is of some use.
I will be on messenger tonight if you want me to help in real time.
Woka
PS. Any comments on my multithraeding code is will be much appreciated.
what about an activex dll or exe or something? lets say I have a main app just used to accept the connections, then from there it spawns a new instance of an activex exe to do the processing, would that work? so the activex exe instance is working but the winsock server is now free to process any new requests, if a request now came in from client 2 it could be processed by a new instance of the activex exe?
What you said is correct about creating an ActiveX EXE. Did you get my file searching example working? That uses exactly what you said in your post. The main server app creates new instances of the ActiveX EXE Wincock app. Each one runs in it's own thread, thus client A and client B can both execute commands syncronously (sp?).
The way you do this is to create an instance of the winsock bit. This instance then listens on a port. When it accepts a connection it sends a msg, to the server, to say that it's been connected. The server app then spawns another instance of the winsock bit, that again listens on a port. So you must always have an instance listening.
You need the multi threading aspect of it because the server and the instances of the winsock bit have to communicate together.
On your server app you are going to have to display the connections somehow. This allows you to stop them and monitor what is going on. The multi threading bit comes in when you need to get info from the connection. You don't want your app to hang before it gets info because the winsock thread is busy, as this will hang your main app, plus you will get that stupid VB error message..."try again" or something...Grrrrrrrr Because it's multithreaded the server runs smoothly regardless of what the threads are doing. This is demonstrated in my file search example in the post above.
I have looked at some of your posts.. are you even a programmer? it seems you just post crap maybe to get your post count up or something.
Woka:
I think I have it sorta working, but I will have to mess with it more to get it how I need it.
There are really only 2 people that will ever connect to the server at one time, but also one person might send a second request to the server before the first request has finished processing, which should be allowed if I can do this correctly.
DiGiTaIErRoR:
The problem isn't with the senddata or getdata, as these fire quickly and only short text trings are being passed. The long processing time comes after specific string data is sent to the server, telling it to perform a job. In this specific case, it is to interact with our CD Duplicator to send a job to that.
Reply With Quote
