Client Server question:Getting client responses in 2 locations, avoiding

Question

I have a client that holds all the connections. Then a GUI running inside the same VM can do specific on demand actions on some selected clients.
I keep all the connections inside a Vector, then in the GUI when I want to send for example to a client a "ver" command the client should respond with his version.
I implemented the behavior but my question is as follows: when I click the ver button on the GUI form, I get the Vector connection from the server class, then I get the associated BufferedReader and PrintWriter from that Vector<Connections>, where Connections is the class that holds socket, bufferedreader and printwriter, I send to selected clients the "ver" string and when a client responds with his version the string is first caught in the ThreadedServer while loop
while ((temp = br.readLine()) != null)instead of the GUI form class or any other class that implements the behavior.
The client should send twice the response. Why is that? And why is firstly caught in the server then in the loop that sended the "ver" command.
Is there a way to avoid this? I mean can I get the response in the method that asked for that version first not in the threaded server that holds all the connections?

Answer 1

1) What will happen ?Depends on what your code does.
2) Will both clients get their own objects seperately ?Depends on what your code does. Remote objects can have an 'id'. If the ids are the same then the same object is produced If not then different objects.
It is likely that your code is using different objects, but that is only a guess.
3) How do they track the use of a method in the remote object ?How does "who" track it? And why would it matter?
A client doesn't 'track' code in a remote object. Basically a RMI proxy sends a message to the RMI server. The RMI server gets the message and processes it. The act of processing causes the object method on the server to be called. When that method exits a message is sent back to the client. At that time the client returns from the method that it called. Notice that the client doesn't do anything with the server code all it does is wait for the message to come back. Does that answer your question?