On Fri, May 19, 2006 at 03:30:29PM +0200, Michal Suchanek wrote: > I guess this may apply to many other services. > > But you wanted a specific example, and I found that I cannot imagine > how ping can be easily implemented without (opaque) constructors.
As a system service. It runs in constant storage (it creates one packet at a time, it needs to wait for the network card anyway if there's another ping busy), so this is no problem. If accounting is required, this uses constant storage per user as well (if done sensibly), so this can be system storage which is conceptually subtracted from the real quota the user should have (so the actual quota is slightly lower). At session creation we are giving the user a quota anyway, so this can be paid from that, by not actually giving it out at all. > In the constructor scenario I can run a service (on user resources) > that does bandwidth accounting that ensures the administrator imposed > network bandwidth policy but uses user memory and CPU time to store > and update the accounting data. > Then ping is a simple program that asks this service (or does a call > and blocks until the service allows its packet). It then sends the > ping, and waits for pong. Any number of (opaque, again) ping instances > can be run at any time. > The privileged network service can then be reduced to some simple > interface like send_packet, receive_packet(_filtered?). This scheme is completely possible if the user donates CPU time to this service (the part which makes the send_packet call) to run (that is, it gives it a scheduling capability). Thanks, Bas -- I encourage people to send encrypted e-mail (see http://www.gnupg.org). If you have problems reading my e-mail, use a better reader. Please send the central message of e-mails as plain text in the message body, not as HTML and definitely not as MS Word. Please do not use the MS Word format for attachments either. For more information, see http://129.125.47.90/e-mail.html
signature.asc
Description: Digital signature
_______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
