Hello, mshauny
I think, I can make it even more complex on an abstract level. You might think, that using two threads sounds complicated, but that is because of the [
TCP/IP protocol>] has a good level of complexity, per se. This is theory :-D .
The implementation: the base socket model implementation goes back to "Berkeley socket model" for handling all kinds of network communications. An implementation of this model can be run in one of two modes, one is
synchron (wait until the operation is ready) and
asynchron (look if this kind of operation event is there and, if it is not there leave the operation, otherwise run the operation) the other one; per socket and independently. But either way will open a single independent socket running on different i/o-channels for safety reasons.
So, there will be a good and, of course, a bad answer, and the good one will promptly follow.
If you really anticipate not to waste much time by communicating over the chat channel (r/w on the network), then you are able to use
one thread for all the actions - listening (which is really accepting connections) and communicating - looping one after another in
asynchron mode,
only; but you will have some work with timing considerations.
If a socket is run in
synchron mode, there is nothing you can do to circumvent a two-threads application, because of
accepting (incomming) connections - if nothing is to accept, the application is really at one with the world and appreciated nothing else but waiting -- a would-be running chat communication channel will be waiting forever.
By the way, how many chat channels will your application open, :-\ ?
The chat client may work as a round-robin task dispatcher (no threads, but in principle) or the chat channels may write their messages into a queue...
As you see, there is much to be considered...
regards,
:cool:h.p.
(software-forge-stghp)
-- don't regret a bad accent - regret a soft brain...:thumbsup:
Submit an article or tip