Command-Based Client (TCP)

[ericV]

Hello Everyone,

I am qurrently working on a TCP-Client, which needs to become command Based.

I have already "prepared" a protocol to this purpose, by sending a command-ID with each data package, which the server can base its response on.

My current problem lies on the fact that i will have many objects sending commands to the server and in some cases they will expect a response.

Now I am unsure how to organize this best specially without blocking the socket.

Should I use Threads for each sender that expects a response?

or

Should I try to implement a ticketing of sorts? For which each command sent will get a number and this will need to be attached to the corresponding response... (sounds complicated! )

or

???

I'm looking for some insight or a nudge in the "right" direction.

(Hope someone understands what i have tried to ask.... :D )

Thanks

Eric

[victor.fernandez]

I faced a similar situation two years ago when we started designing an application that communicates with an Asterisk Manager (plain text messages on port 5038).

I created a thread that connects and manages the messages. It uses an event loop and non-blocking API. A private class parses the messages and emits a signal for every kind of event. In every part of the program that needs a response, you can just connect the signal to a slot.

It's working pretty fine. You could the same.

[ericV]

Thank you for that.

I am still strugling a bit with this problem, here is why:

- my application will have many different grafical objects, which may request different types of data from the server.

So i need to identify the request sender somehow in order to send the response to the "right" object.

I am running around in circles because of this....

Had thought about using QLocalServer with QLocalSockets from each object... but it seems to me that this wouldnt be the best way....

An other idea that I have, is to create a RequestThread... that can be called from each object... which then emits a signal when the response has arrived (probably a cleaner aproach)

I will try to experiment on this...

[victor.fernandez]

Use signals and slots. An object that needs some type of data should connect a signal from the server to itself. When the object wants to request some particular data, it would call one of the server backend slots and some time later one of the object's slots would be invoked. This way the server doesn't need to care about your objects.