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/e6310e92/attachment.pgp>
