On Thursday 27 August 2009 23:42:00 Michael Yip wrote: > Hi Matt, > > What about PersistentPut request with persistence = forever. If I remove > the request, would the insert be removed as well?
Each request or insert is separate, with its own Identifier. And there is no way to remove content once it is out on the network. > > 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. -------------- 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/aa9f6bed/attachment.pgp>
