On Wed, 15 Apr 2009, [email protected] wrote:
The figure in seection 2 describes ToU as a library. This is desirable for quick adoption, but is basically an implementation detail.
Indeed.
The socket-like API in section 5 is of limited use if you want to mix ordinary file descriptors and libraries with ToU sockets (eg gtk_input_add, or Qt's QSocketNotifier). DLL trickeries might give better results.
Right. The socket-like API was merely intended as a reference.
The draft doesn't discuss any timing constraints that a library implementer would have to meet: is it enough to check timers on every tou_ call? Or do I need a background thread?
This is an implementation choice: both timers on a tou_call or a background thread will work.
What information needs to be shared among several applications using ToU, like ISN and TCBs? Is this even possible if applications on a single system use different ToU libraries?
As long as the underlying OS does not support ToU, applications on a single system may use multiple ToU libraries.
(should this draft be discussed in p2psip or tsvwg?)
Yes. We presented this straw man version on p2psip mailing list since this WG is currently the biggest customer of ToU. We are planning to update the draft with the comments gathered so far, and present it to tsvwg.
-s _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
