On Thursday 27 August 2009 22:22:41 Evan Daniel wrote: > 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.
Apart from what evanbd said, I should point out that you will only get the persistent requests on connect if you started persistent requests, they completed, and you didn't remove them. Normally you should remove them when they complete. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20090827/36c61519/attachment.pgp>
