Questions on simple client-server app

[worwhite]

Hi,

I am writing a simple multithreaded client-server application using sockets, and have a few questions:

1. For the client, is it really necessary to use a separate thread (i.e. of the java Thread class) for receiving data from server?

Many resources I found use the client object to send data (using dataOutputStream) to the server, while employing a single thread specifically to receive data (using dataInputStream) from the server. This is supposedly because I/O streams are blocking by nature, so a single thread of execution shouldn't be able to send data (or do anything else) while waiting for a server message because the program is blocked until something is received.

However, the client I wrote could do sending and receiving without using a separate thread. The code to receive data (i.e. socket.readUTF()) was put in a while loop, and the code to send data (i.e. socket.writeUTF()) was in the actionPerformed() method (to be triggered when user clicked a button). As far as I can tell, while the user did nothing, program execution remained in the while loop, listening for server message. When the user clicks the button, the actionPerformed() method was triggered, "interrupting" the while loop and sending a message. Once done, the program went back to listening. The sending and receiving worked perfectly.

Why then do people use a separate thread?

2. If i decide to use a separate thread for receiving do I need to make the client object a thread as well? Or can I just run the client as an object? I'm asking this because I noticed some people ran the client object as a thread.

I'm not too sure why they did that because as far as I can tell, when you create an object and a thread, they run concurrently (i.e. like two threads would). Since only one object is involved in this case (the client), it shouldn't need to be run as a thread, right? Or am I missing something?

3. Does an object need to acquire the lock in order to access its own method, if that method is synchronized? Here's my situation:

My server is implemented as an object. Session threads are created for each client connection. Each session thread calls the server object's handle() method whenever it receives a client request. The handle method is synchronized, and sends return information to the client.

Apart from the handle() method, the server also has some other methods that send information to each client. These methods can be called at any time through the server's GUI (they are not called by the session threads). While the handle() method is running, I DO NOT want these other methods to run because they may interfere with handle() and mess up the sending protocol. In other words, I want the handle method to finish before these other methods are run.

Can I make these methods synchronized in order to prevent the server object from calling them when the handle method is running, and vice versa? Theoretically the server object would need to wait for the handle's lock to be released before it could call them. I'm just not sure if an object (not thread) would need to acquire the lock on its own synchronized method in order to access it. Hence my question.


Sorry for the lack of brevity, but I wanted to be as clear as possible. Explanations and feedback are very much appreciated.

Thanks in advance.

[Norm]

is it really necessary to use a separate thread for receiving data from server?

How does the client work? Does it send a message to the server and then wait for the response?
If you need the client to be doing something else while it is waiting for the response, then put the connect and read response code on another thread to allow the something else to be done.

[worwhite]

My client needs to be able to send messages while waiting for responses/server messages. It's not a case of send -> receive -> send receive etc.. The server may choose to send a message at any time, not necessarily just after a client request. Besides that it doesn't really do anything that takes up a substantial amount of time.

[Norm]

Then you would need to use a thread for each send message/receive response communication.

[worwhite]

Then you would need to use a thread for each send message/receive response communication.

Ah that's my first question - I didn't... and it still worked. Oh and my second question is whether you need a thread for BOTH send/receive. Can I use a thread for receive and just the client object for sending? They still run concurrently right?

[Norm]

Can I use a thread for receive and just the client object for sending?

Not sure what would happen or why you want to do it that way.
What do you mean by the "client object"? Execution is in threads. Objects contain methods and data.
I would create a thread for each message being sent with it waiting for the response after sending the message. Separating the sending from the waiting for response doesn't make sense to me. Usually the response is related to the message that was sent. You'd want to know what message was sent to generate the received response.

[worwhite]

Hmm client object as in an instance of the class that is created. It's executing but it's not created as a Thread (does not extend Thread or implement Runnable).
In this case we need to separate them - it's not a structured protocol as i explained. It's something like an IRC chat-server. You can receive chat messages from the server at any time, not just after you have sent a chat message.

[Norm]

It's executing but it's not created as a Thread

All code executes on a thread.

It's something like an IRC chat-server.

That makes the communications like broadcasts. There are no expected responses to the message being sent. So there is no waiting for the response. Send the message and return. There would be a loop that waits to receive the next message from the server.

[worwhite]

Ah from what I know there's a bit of a distinction between an instantiated object and a thread. Threads can run concurrently to each other, while objects can't - if you have two objects they run iteratively.

From what i read the loop that waits to receive the next message should prevent anything from being sent. Here's an answer from another forum that may answer this question (he's right I'm using swing):

"The Sending & receiving works fine because you are using a swing application. a swing app is started as a thread & any actions performed are a part of the EventListener thread (i'm not quite sure of the exact name of the thread though)..

you have a while loop running in a thread & whenever a user wants to send something to the server it uses the eventlistener thread to do the job.. Thats why you don't see the program lagging.."

Would love an answer to my other questions if anyone knows.

[Norm]

while objects can't

objects don't execute. The code in an object executes on a thread. In fact the code in an object can execute on several different threads concurrently.

the loop that waits to receive the next message should prevent anything from being sent

If the loop that waits is on its own thread, it should not prevent code executing on another thread from doing what ever it wants.

[worwhite]

To clarify: When I say object - I just mean an object (i.e. instance of a class) that is not a java Thread (i.e. does not extend the Thread class). When I say Thread, I am not refer to a generic concept of a thread of execution - I am referring to the java Thread class. Objects (or object code, if you prefer) may be run as a thread of execution in the JVM, but that's not the same as saying it is a Java thread.

The client object that I have do not consist of threads - its code is sequentially line by line.

[Norm]

Ok. But bottom line: all code executes on a thread. Your program is given one thread to execute on when it starts. If you need more, use the Thread class to ask the JVM to give you another one.

[worwhite]

That's what I was asking...I'm supposed to need more, but I didn't. In any case this first question has already been answered in another forum. Still need answers to questions 2 and 3 if anyone knows.

[Norm]

I'm always interested in learning new techniques:
If the client does not have a separate thread for listening for messages from the server, how does it work?
One way clients work is to build a GUI, connect to the server, start a thread to handle the messages from the server and exit back to the JVM to await user input to the GUI and/or message from the server.

[Norm]

this first question has already been answered in another forum

Please post a link to the other forum.

[Sean4u]

You do have two threads in your client:
The Event Dispatch Thread (The Java™ Tutorials > Creating a GUI With JFC/Swing > Concurrency in Swing)

I would usually do something similar to what Norm suggests: having one thread each for send and receive, with GUI events handing off their messages to the sending thread to make sure that the actionPerformed() methods return quickly and don't tie up the Event Dispatch Thread.

[worwhite]

Yes Sean4u. Thanks for pointing that out - that's the same answer given in another forum. Hmm ok I take your point about not tying up the event dispatch Thread. I guess it's good programming practice to run client listener and receiver on two threads. My next question, (question 2) should they (sender and receiver) BOTH have to extend the Thread class? or only one (e.g. the receiver)?

Norm I already posted the answer given in that forum in one of my replies to you on page one... here's the link anyway
java - Some questions on simple client server socket app - Stack Overflow

Yes it means that my object actually does have threads due to the swing class. I take back my previous statement that "The client object that I have do not consist of threads - its code is sequentially line by line." -, that was my original perception, and the threads was pointed out by the person in the other forum quite a while ago.

Again, I already understand that the answer to question 1 is that my client object actually does have threads because Swing uses thread and my object is a Swing component.



I still don't have an answer to questions 2 and 3. To repeat:

Question 2: Does anyone know if both the sending and receiving parts of the client have to extend the Thread class? Or only one? I'm thinking of this:

Client (sending part) - Does not extend Thread. Also handles any server message received from the receiving part
Client (receiving part) - Extends thread. Sends any received server message to sending part for handling.

Assuming that in this case I do NOT use Swing (i.e. the sending part is not run as a java Thread), will these two parts run concurrently and work properly as a client?

Question 3: If i run an object (or object code) that is does not extend the Thread class, and the object contains synchronized methods, does it need to acquire the lock to access its synchronized methods given?

Thanks in advance.
I'll do some experimentation myself in the meantime. But I would like to know the theory instead of just whether something works or not (I already tested my program - it works, just want to know why it works or whether it's working in the way i think it's working).

[Norm]

Does anyone know if both the sending and receiving parts of the client have to extend the Thread class?

None of them do.

If i run an object (or object code) that is does not extend the Thread class,

Extending the Thread class is not an issue.

[worwhite]

None of them do.

Extending the Thread class is not an issue.

Can you explain why?

[Norm]

neither the sending and receiving parts has to be a java Thread?

Yes that is what I mean.
All code runs on a thread. You can get a thread several ways.
Extending Thread is ONE way. Using new Thread() is another way to create a new thread when you need to have your own background thread to let the GUI thread/Swing EDT do its thing.
Also there is the Swing Timer class that will get you a thread and many other classes that handle threads for you.

[worwhite]

....
You are saying that BOTH the sending and receiving parts HAVE to be a java Thread regardless of which way you do it. What you are telling me is that I do not need to extend a the Thread class to get a Tread. I already know that, and it does not answer my question.

I used extending Thread to clarify that i mean it being run as a java Thread. To clarify it again for you Norm, let me rephrase my questions:


Question 2: Assuming that I am not using Swing, does anyone know if I have to create a java Thread (from the class Thread) for both the sending and receiving parts of the client? Or only one? I'm thinking of this:

Client (sending part) - Does not extend Thread. Also handles any server message received from the receiving part
Client (receiving part) - Extends thread. Sends any received server message to sending part for handling.

Will these two parts run concurrently and work properly as a client?

Question 3: If i run an object (or object code) that is not a java Thread (i.e. from the class Thread), and the object contains synchronized methods, does it need to acquire the lock to access its synchronized methods given?

Again, I know that all codes run on a thread of execution. I would not ask something inane - please take Thread as something that I SPECIFICALLY created through extending Thread, implementing runnable() and using new Thread(runnableClass) or whatever.

[Norm]

if I have to create a java Thread (from the class Thread) for both the sending and receiving parts of the client?

One thread you are given by the JVM. Use that one to handle user input.
You create one thread to wait on the messages from the server.

If i run an object (or object code) that is not a java Thread

None of the code I've written that has used synchronized methods has extended the Thread class.

does it need to acquire the lock to access its synchronized methods

Read the API doc for the Object class wait and notify methods.

[worwhite]

Hmm was reading the wait and notify methods as you suggested, here's a pertinent part that I got:

This method should only be called by a thread that is the owner of this object's monitor. A thread becomes the owner of the object's monitor in one of three ways:

* By executing a synchronized instance method of that object.
* By executing the body of a synchronized statement that synchronizes on the object.
* For objects of type Class, by executing a synchronized static method of that class.

Only one thread at a time can own an object's monitor.

To be absolutely sure - the thread they are referring to (the one I placed in bold), refers to any thread of execution, and CAN be the object (which is not a java Thread/does not extend the Thread class/was not created using new Thread()/but is still a thread of execution in the JVM)? So an object (which is not a java Thread/does not extend the Thread class/was not created using new Thread()) calling its own synchronized method still has to acquire the lock - it has to compete with other Threads (extend the java class/created using new Thread())?

[Norm]

Forget about the source of a thread. That is not important. All code executes on a thread. Then consider what the API doc that you read says:
Only one thread at a time can own an object's monitor.

[worwhite]

Ah I see. Thanks Norm.