Hi Matt, What about PersistentPut request with persistence = forever. If I remove the request, would the insert be removed as well?
Thanks, Michael Matthew Toseland wrote: > On Thursday 27 August 2009 22:35:57 Michael Yip wrote: > >> 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? >> > > No. Well, if you download to disk, it won't delete the file. If you download > to temporary space, it will delete the data from temporary space. > > >> I have >> to say this auto-listing of existing Persistent requests is pretty >> annoying. Why does it need to be on auto? >> > > To prevent careless client authors from leaking disk space! > >> 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
