Depends on the size of the data being stored. For any of the currently proposed usages, the sizes are low, so carrying the data is essentially free. If a refresh was added for efficiency with potential large objects, there would have to be a corresponding error code and subsequent store of the data in case it's been lost.
Given that the protocol isn't really designed for storing large objects in the overlay as it currently stands, I think such support would just add unnecessary complication. Bruce 2010/1/25 JeffreyHo <[email protected]> > Dear all, > > Any comments or idea on this question? > I think if we can just specify the refresh purpose in the StoreReq instead > of sending a full StoreReq for refresh, it can mitigate the traffic load, > right? > Welcome to any discussion and feedback. > > BR, > Jeffrey > > ------------------------------ > *From:* [email protected] [mailto:[email protected]] *On > Behalf Of *JeffreyHo > *Sent:* Friday, January 22, 2010 3:11 PM > *To:* [email protected] > *Cc:* 沈婉婉shen > *Subject:* [P2PSIP] [p2psip] asking about the lifetime of the stored data > andrefreshing mechanism > > Dear all, > > I would like to ask a question about the lifetime of the stored data and > refresh behavior sequentially. > The 'lifetime' field of RELOAD's StoredData structure specifies the > validity period for the data, that is the expiration time in the overlay. > So if the data owner wants to keep the data previously stored still > validity, the refresh behavior is necessary, just like the registration > refresh in SIP Concept. > > Based on the StoredData structure if we want to do refresh for the data, it > seems that we can just send StoreReq with the content of data again to renew > the 'lifetime' value. Am I right? If so, this seems in the wasted way. > Can we have an efficient way to do the refresh behavior, for example just > bringing the lifetime value to be renewed for the data, not going along with > the data content? It could be like the refresh mechanism of SIP > registration or presence publication. Should we go this way? > > Thanks a lot. > > BR, > Jeffrey > 本信件可能包含工研院機密資訊，非指定之收件者，請勿使用或揭露本信件內容，並請銷毀此信件。 > This email may contain confidential information. Please do not use or > disclose it in any way and delete it if you are not the intended recipient. > 本信件可能包含工研院機密資訊，非指定之收件者，請勿使用或揭露本信件內容，並請銷毀此信件。 > This email may contain confidential information. Please do not use or > disclose it in any way and delete it if you are not the intended recipient. > > _______________________________________________ > P2PSIP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/p2psip > >
_______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
