Originally posted by Stan James:
I took "at the same time" to rule synchronizing like that out, but it oughtta help.
I also understood the trouble with "individual threads sending messages (synchronously) over the same socket ..." and wanted to try individual threads sending messages over different client sockets. If the server is built in a conventional manner it will accept many client threads connecting to the same server socket at the same time.
Originally posted by Ernest Friedman-Hill:
The client threads need to do the entire "send message, read response" sequence while holding onto a single shared lock object. i.e., what you're describing will work perfectly fine if you do
Assuming, of course, that the server is designed to handle multiple messages on a single client connection.
Make sense? I'm not sure why no one has explained this already.
Originally posted by Stan James:
So poke around a bit ... what does the server do if you open multiple sockets from the client? The code I showed is almost pseudo code for any self respecting server. It might behave perfectly. Or not.![]()
If you send multiple messages over the same socket and look for responses to come back possibly out of order, you're into classic asnychronous mode. Messaging products like MQ-Series create a "correlation id" when they send the request, and put the same id on the response. That helps you know which requester wants each response. I think I have a bit on this HERE.