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<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
