Multiple TCP/IP apps

Stefan Kalkowski stefan.kalkowski at ...1...
Thu May 12 22:48:36 CEST 2011


Hello Александр,

On 05/12/2011 07:05 PM, Александр Домо wrote:
> Hello, again!
>
> Could you please suggest the proper way to use the lwip library in
> multiple processes, especially, with libc_lwip_nic_dhcp?
>
>  From my point of view, lwip alone should work ok in multiple
processes, as
> long as a static IP-address is assigned. Those processes start
> communicating with the nic driver and just work along. Or they don't?
>
> As for the dhcp part, it gets more complicated. Do they all get the same
> IP address? As far as I know DHCP, they do. But I don't think this is
> really nice, when all the applications start querying for IP addresses.
>

to share one NIC between several processes running lwip, we provide a
special component, called nic_bridge (in os/src/server/nic_bridge). It's
an implementation of the Proxy ARP concept, please have a look here:

  http://en.wikipedia.org/wiki/Proxy_ARP

In short, it virtualizes the NIC-session. For the several lwip-stacks it
provides the same interface, like our NIC-drivers. The nic_bridge itself
is the only client of a NIC-driver. This component inspects in- and
outgoing ethernet frames, and slightly modifies ARP and DHCP packets.

During initialization, every lwip stack gets its own MAC-address. When
it issues a DHCP request, the nic_bridge has to be aware of the
IP-address assigned to it. Whenever, an ARP-request for one of the
assigned IP-addresses is received from the outside, the nic_bridge has
to answer with the real MAC-address of the NIC. When an IP packet
arrives it will get routed to the right lwip-stack, because the
nic_bridge knows the mapping of IP-addresses to its clients. In all
outgoing packets, the sender-MAC has to be replaced by the NIC's
MAC-address. That's it. This allows several lwip-stacks with different
IP-addresses working on the same NIC.

The only potential drawback is the increased number of IP-addresses
needed, which for some rare scenarios might be a problem.

> Maybe I should write a real, hard-core, independent TCP/IP module, which  
> would offer IP services to everyone else, like it's done in QNX, for  
> example? But that's not so easy, right? I'd prefer the easy way first ;)

Yeah, you're right. Something like a socket-server would be a very
sophisticated component, and would highly increase the complexity of the
trusted computing base of all applications, that depend on such a
component. If you like to code a network component for Genode, which
enables sharing of one IP-address from the network below between several
Genode applications, I would advice you to better write some kind of a
IP router, that builds a separate subnet for it's clients, and routes
between that network and the outside world.

But if you are fine with all Genode applications getting there own
IP-address from your DHCP server, the nic_bridge meets your needs.

> 
> Thanks!!
> 

I hope that helps.

Regards
Stefan

> ------------------------------------------------------------------------------
> Achieve unprecedented app performance and reliability
> What every C/C++ and Fortran developer should know.
> Learn how Intel has extended the reach of its next-generation tools
> to help boost performance applications - inlcuding clusters.
> http://p.sf.net/sfu/intel-dev2devmay
> _______________________________________________
> Genode-main mailing list
> Genode-main at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/genode-main
> 

-- 
Stefan Kalkowski
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




More information about the users mailing list