On Thu, Aug 27, 2009 at 5:00 PM, Michael Yip<mhy831 at cs.bham.ac.uk> wrote: > Hi Matt, > > I know the ListPersistentRequests request and how it works. The problem > lies in the interaction: > > 1. My client sends a ClientHello > 2. Node replies with a NodeHello > 3. Node sends a list of Persistent requests (PROBLEM! How do I determine > when it would end?) > 4. My client send desired requests and handle replies specific to the > request. > > My problem is that the reader cannot terminate reading from stream at > step 3 and so I can't do the things I want to do at step 4. > > Thanks for your help. > > Michael
It does not need to terminate step 3 to start step 4. If you want a complete list, use the ListPersistentRequests command toad mentioned. Aside from that, just handle every message received when it comes in, and send messages when you're ready to send them. FCP is a non-blocking protocol. There is no requirement to wait for a response from one request before sending a new request. There is no guarantee that responses will arrive promptly or in order. Your client should not block completely while waiting for a response from the node, though obviously individual actions have dependencies. Obviously you don't have to write a multi-threaded client to handle this, but it is probably the most natural fit to the protocol. Any messages unrelated to what your client is doing can generally be ignored, and should be -- for example, new status messages have been added since some client tools were written, and those tools continue to work fine, they just ignore the new status messages because they don't know what to do with them. Conceptually, a user tool to monitor the queue and download / upload files would go something like this: - set up connection (ClientHello, etc) - Display the currently active downloads pane, initially empty - Begin accepting user input to upload / download new files. Then, at any point, before, during, or after the user adds a new file to download, if the node received a status message about a persistent download, it would add it to the displayed list. Similarly, if at any point the user started a new download, the client would send that info the node, regardless of the current state of the list or whether the node was still telling it about things in it. Evan Daniel P.S. It would be nice if you kept replies to messages in the same thread; it makes them display more cleanly on many mail clients.
