*Hi Norman,*
*I am little confused . Do i need to change all the liwp socket calls wich
has blocking property like (accept , recvfrom,etc ) with non blocking
calls, then I need to use asynchronous notifications. instead of using
Block RPC calls , *
*thanks*
2014-05-28 19:30 GMT+01:00 Norman Feske <[email protected]>:
> Hi Mohammad,
>
> the steps you described look plausible to me.
>
> > What I am Facing:
> >
> > - when i tried to run more then one echo server ( in different port)
> > ,the lwip is
> > not working will and what i found that when the tow echo server
> > try to accept
> > connection the first one will block the other. and it means that
> > lwip is not multi threading any more.
> > Is the RPC prevent the lwip multi-threading or I am doing some thing
> > wrong .
> > I maنe my problem easy to be understood, if not just ask me to
> clarify.
>
> According to your server-side code, there is only a single entrypoint
> thread that serves the requests for all clients. While one client issues
> a blocking call (i.e., accept), the entrypoint thread cannot process RPC
> requests for other clients. All RPC calls are processed in a serialized
> way.
>
> There are two possible ways to solve this issue. You can either (1)
> remove blocking RPC calls from the RPC interface or (2) make the server
> multi-threaded (using one entrypoint per session).
>
> If you go for (1), how to implement blocking functions like accept,
> then? The solution is the use of asynchronous notifications. Instead of
> issuing a blocking RPC call, the client would register a signal handler
> at the server. It would then issue a non-blocking version of RPC
> function (which immediately returns) and subsequently wait for a signal
> from the server. In contrast to the blocking RPC call, in this scenario
> the blocking happens at the client side only. So the server can keep
> handling other incoming RPC requests. Of course, on the server side,
> this asynchronous mode of operation must be implemented accordingly,
> e.g., by using 'select' in main program. So the server cannot remain a
> mere wrapper around the lwip API.
>
> If you go for (2), you have to implement the 'Root_component' class by
> yourself. Each 'Session_component' would contain a 'Rpc_entrypoint' that
> manages the single 'Session_component' only. Effectively, each time a
> client creates a connection, a dedicated entrypoint thread gets created.
> Unfortunately, the current version of Genode does not feature an example
> for a server that uses one entrypoint per session. However, once (like
> two years ago), there existed a version of the timer driver for NOVA
> that employed this scheme. You may take this code as inspiration:
>
>
>
> https://github.com/genodelabs/genode/tree/b54bdea2aae245b2d8f53794c1c1b9b2da371592/os/src/drivers/timer/nova
>
> Which would be the preferable way to go? I would definitely go for (1)
> because this solution would be much cleaner and more light-weight (i.e.,
> you'd not need a thread per client). However, I am afraid that it is
> more elaborative than (2) because you will need to model your server as
> a state machine. The normal BSD socket interface uses blocking calls for
> accept. So you'd need to replace them by an asynchronous alternative,
> possibly diving right into the inner realms of the lwIP stack to
> accomplish that.
>
> Btw, if you look at recent implementations of services on Genode, you
> will find that all new servers have embraced the asynchronous design.
> E.g., take a look at how 'Timer_session::msleep()' works as an example.
>
> Still, exploring (2) might be a worthwhile experiment and a useful
> interim solution.
>
> Cheers
> Norman
>
> --
> Dr.-Ing. Norman Feske
> Genode Labs
>
> http://www.genode-labs.com · http://genode.org
>
> Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
> Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
>
>
> ------------------------------------------------------------------------------
> Time is money. Stop wasting it! Get your web API in 5 minutes.
> www.restlet.com/download
> http://p.sf.net/sfu/restlet
> _______________________________________________
> Genode-main mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/genode-main
>
--
*Mohammad*
------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
_______________________________________________
genode-main mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/genode-main
