Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>A <code>socket</code> (in networking terms) consists of 2 endpoints (The client and the server app) and 2 <code>streams</code>. The output stream of the client is the input stream of the server and vice versa.</p> <p>Now try to imagine what happens if a thread writes a lot of data to a stream while no one reads... There are buffers, true, but they aren't unlimited and they can vary in size. In the end your writing thread will hit the limit of the buffer and will block until someone frees the buffer.</p> <p>Having said that, you should now be aware that this will need at least two different threads per Stream: one that writes and one that reads the written bytes.</p> <p>If your protocol is request-response style, you could stick with 2 threads per socket, but no less.</p> <p>You could try to replace the networking part of your application. Just create an abstract interface where you can hide the whole networking part, like:</p> <pre><code>interface MyCommunicator{ public void send(MyObject object); public void addReader(MyReader reader); } interface MyReader{ //See Observer Pattern for more details public void received(MyObject object); } </code></pre> <p>This way you could easily remove the whole networking (including en- &amp; decoding of your objects, etc) and minimize threading.</p> <p>If you want the data binary, you could use pipes instead or implement your own streams to prevent threading. The business or processing logic should not know about sockets, streams are low-level enough and maybe too much.</p> <p>But either way: Threading isn't bad, as long as you don't overuse it.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload