Server sends unknown number of messages, client doesn't know when he stops
So I am trying a simple server-client experiment for an exercise I have to do. I have a simple server-client model over the Internet working with tcp sockets.
I set up the server and he starts accepting connections from clients and then proceeds to create a new thread for every client to further serve him.
A client, after it connects to the server sends questions/commands to the server who then proceeds to answer them with a message. The content depends on some files on the server and they have nothing to do with my question.
So my questions is the following: Sometimes the server can't answer in one message and has to send multiple messages to the client but the client never knows when this might happen and the server doesn't know how many messages it might take (only when it has sent the last message of the answer) and I want to know of a way to control this exchange.
Some things I thought of are these but I am not sure about them. I feel as though they have too many control statements or what not. I know that such a simple program is nothing to computers these days but I am trying to form ideas with performance as the goal
1)The server always sends after the last message a message that indicates that he will not send any further message but again the client still has to check every message. Though I can change it to check every message after the first so I save one check. (It is possible that most answers will need only one message)
2)I add a prefix to every answer so that a part of the answer has a number (sequence number perhaps) and the final part has something to indicate as such (this only I can manage so that the client knows in how many messages it will answer)
Anyway, I am interested in general in methods of two programs communicating when there is no fixed structure in the way the messages are exchanged (first the client asks, then the server responds, then the server again sends some other message, and then the client sends another...) or does that not happen.