This discussion is archived
5 Replies Latest reply: Apr 30, 2013 4:04 PM by EJP RSS

Confused about design when using NIO paradigm

mauric Newbie
Currently Being Moderated
Good morning,

I'm currently studying NIO in order of implementing a custom client-server protocol, and I get a bit confused about NIO effective usage.
As far as I undestood from material I've read, NIO is intrinsically a non-blocking and, as a consequence, an asynchronous way to execute request on (and read response from) a remote server. Looking at most of the example I've found on the web, the general idea behind server-side NIO programming may be summarized as follows:

- create a single I/O worker thread, which reads in a non-blocking way as many data as possibile from each requests;
- all read data must be incapsulated in a "message" or "request" - so that there must be a mean to identify a "complete" request;
- all requests are queued and processed by "worker threads" which produce "responses";
- responses are sent back to clients using the I/O worker thread.

I don't know if I understood well this model, anyway I haven't had big troubles in figuring out how it works. Instead, I'm really confused on how I should develop my client, since most examples I've found use an asynchronous approach even on client side. Normally I need to send a request and wait for a response in a blocking way: a common scenario is GUI's usage in which user execute a request and must wait untill server sends back a response. It seems that I cannot mix blocking IO on client and non blocking IO on server.

So, I tried to mix up things using this approach: I wrote a sendRequest method which:
- uses client's opened channel to write the request;
- the actual read on client's channel is performed by an Handler, which runs in a separate thread; both sendRequest and Handler share a Lock object
- sendRequest writes request to the server and suspend on the lock;
- sendRequest must be notified by Handler thread when response has arrived, and only then may return.

In a nutshell this client design works specularly as server design does, with the difference that the calling thread is actually blocked until response is ready.

I'm asking your help to verify how much I'm far away to a solid understanding on how a NIO server-client should work....

Thanks in advance !
  • 1. Re: Confused about design when using NIO paradigm
    EJP Guru
    Currently Being Moderated
    NIO is intrinsically a non-blocking
    No. That is one of its operating modes.
    an asynchronous way
    No. Non-blocking is not the same as asynchronous. Non-blocking means that the I/O data transfer happens while you call the method to the extent that it can be transferred without blocking. Asynchronous I/O is another model altogether where you initiate a transfer and get a callback or deferred result via a second API.
    the general idea behind server-side NIO programming may be summarized as follows:

    - create a single I/O worker thread, which reads in a non-blocking way as many data as possibile from each requests;
    Correct, more or less, except that you aren't limited to a single thread, you can have as many Selectors and therefore as many threads as you like: you can also have worker threads for the selector threads (although I have never seen an architecture where this actually works properly).
    - all read data must be incapsulated in a "message" or "request" - so that there must be a mean to identify a "complete" request;
    Correct.
    - all requests are queued and processed by "worker threads" which produce "responses";
    Not necessarily. Requests can be processed entirely by the thread that read them, if there is no blocking required for that processing
    - responses are sent back to clients using the I/O worker thread.
    Not necessarily, although again I've never seen a convincing architecture using more threads that actually works.
    I'm really confused on how I should develop my client, since most examples I've found use an asynchronous approach even on client side.
    I have no idea why, even assuming you mean 'non-blocking'. Unless your client deals with multiple servers at the same time, there is absolutely zero reason to use NIO in the client, and you would have to deal with hundreds of servers to make it really worth your while.
    It seems that I cannot mix blocking IO on client and non blocking IO on server.
    That is completely incorrect. The server has no way of knowing how the client is implemented, and vice versa.

    I strongly recommend you use java.net blocking I/O in the client. It's easy to get working and it lets you concentrate on getting your server working, instead of having non-working code at both ends.
  • 2. Re: Confused about design when using NIO paradigm
    mauric Newbie
    Currently Being Moderated
    Thank you very much for your quick answer, you helped me a lot. I think I will review my work about NIO, expecially on developing client side communication....and that I'll post here more other doubts that I'm sure will populate my mind :-)

    Thank you again !
  • 3. Re: Confused about design when using NIO paradigm
    sabre150 Expert
    Currently Being Moderated
    EJP wrote:
    I have no idea why, even assuming you mean 'non-blocking'. Unless your client deals with multiple servers at the same time, there is absolutely zero reason to use NIO in the client, and you would have to deal with hundreds of servers to make it really worth your while.
    In my recent client/server application I implemented both the client and server using non-blocking NIO because the client and server then have much code in common (50 odd %) and my client at times itself acts as a server. I'm not suggesting this is the best approach but it did give me much insight into how NIO in non-blocking mode should/could be used.
  • 4. Re: Confused about design when using NIO paradigm
    1006425 Newbie
    Currently Being Moderated
    I have no idea why, even assuming you mean 'non-blocking'. Unless your client deals with multiple servers at the same time, there is absolutely zero reason to use NIO in the client, and you would have to deal with hundreds of servers to make it really worth your while.
    Might NIO be a good solution for a case where you have multiple client connections in one process? They could share a selector so only one thread blocks for the select() calls, then that thread could invoke other threads (maybe from a shared thread pool) for any time-consuming functionality. I'm considering this type of architecture and am looking for pros, cons, or alternate designs.
  • 5. Re: Confused about design when using NIO paradigm
    EJP Guru
    Currently Being Moderated
    I've never understood the need for client-side NIO. You don't have thousands of connections, you don't need non-blocking mode, the servers you talk to are probably all completely different: using different threads is just far easier to code.

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points