title: Netty App Design For Large Number of Small Transfers
body: <p>I'm trying to decide how to design a Netty app with what I think are some unusual requirements.  Basically there's a client that initiates a request.  That request translates into English as "Go recursively get a bunch of little tiny files under directory /whatever/, and all I can tell you about those files is that their names are between AAAAAAA.bin and CCCCCCC.bin".  </p>
  
  <p>So, the server needs to take the request, and start scanning some directories on the server side, and start rapidly streaming all these little files back.  Performance is critical, but so is making sure that I've received all files between AAAAAAA.bin and CCCCCCC.bin.</p>
  
  <p>So would it be a good design to make the client and server basically asynchronus themselves?  In other words, the client initiates the conversation, sends the request, and simply receives an acknowledgement UUID token or something, and then the server begins gathering up files (maybe one per thread), contacts the client, and hands it a single file along with the UUID?  I'm thinking that the client could periodically ask the server "are you done streaming my request that matched UUID token /sometoken/?</p>
  
  <p>I'm not quite sure how this would be configured, since the client and server both would be initiating conversations.  Or, maybe someone else has a better design idea?  Again, performance (total time from request initiation to completion of all file transfers) is critical.</p>
  
  <p>Thanks!</p>