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.
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 ;)
Thanks!!
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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main