Thanks Matt, you've been very helpful to me!! Matthew Toseland wrote: > 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<[email protected]> 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 >>>>> [email protected] >>>>> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
_______________________________________________ Devl mailing list [email protected] http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
