Hi Evan, Matt, Thanks for your replies.
Ar, I didn't know it's a non-blocking protocol. That means if I send a PersistentPut or PersistentGet, I should continue reading from stream until I get the relevant end messages with the specific identifier. Matt has said that I should remove the Persistent requests once they are completed but that would remove the file I inserted/retrieved? I have to say this auto-listing of existing Persistent requests is pretty annoying. Why does it need to be on auto? Thanks, Michael Matthew Toseland wrote: > 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. > > ------------------------------------------------------------------------ > > _______________________________________________ > Devl mailing list > Devl at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
