emery at ...261...
Mon Mar 27 18:17:02 CEST 2017
In my opinion, once you start using TCP/IP, you cross a complexity
threshold where it makes sense to use high-level langauges or
The alternative would be to use the lwIP raw API and avoid libc, but
this is not exposed right now. Another option would be the Rust way, I
expect there is atleast Rust TCP stack in the works, so in theory a
Rust component could be crafted to use Nic sessions directly.
On Mon, 27 Mar 2017 13:25:43 +0200
Christian Helmuth <christian.helmuth at ...1...> wrote:
> Hello Boris,
> On Mon, Mar 13, 2017 at 03:48:54PM +0100, Boris Mulder wrote:
> > 1. In the release notes you describe the support for async file I/O.
> > However, it seems that while asynchronous I/O works now,
> > synchronous I/O is no longer possible. When I remove the select()
> > call in the echo scenario, the call to recvfrom() will fail saying
> > the socket is not connected (even though it is an UDP socket and
> > should not have the notion of connections at all).
> > Of course this means it is not posix compatible; the intended
> > behaviour is to block until data becomes available.
> Thanks for your investigation. You're right the current state of
> socket support has some rough edges (esp. POSIX-correct error
> handling) that we plan to smoothen in near term. I'd like to invite
> you to open an issue at Github to aggregate your findings.
> > 2. Currently there are two ways an application can use tcp/ip
> > sockets from the lxip stack: By using libc sockets, and by directly
> > opening a file system session and writing to the right socket
> > files. For any new Genode application that does not already depend
> > on libc, the first way means you unnecessarily add the entirety of
> > libc to your component. So the second way seems preferred.
> > However, when programming an application using a file system
> > session directly adds a lot of code with many open()s, read()s and
> > write()s that could be abbreviated into single calls such as
> > connect() and recv(). Have you thought of providing a more
> > convenient API (such an object-oriented Socket class that hides the
> > vfs calls from the application programmer)? Or do you consider
> > using the fs session interface to be better? If so, why?
> We do not plan to implement an abstraction layer or object-oriented
> Socket interface currently. The mere reason for our recent
> developments was to enable more POSIX network applications to run on
> Genode and to support those components to share one network stack.
> Also, we imagine to mount the socket FS into Noux and use traditional
> tools in shell scripts to interoperate with the network.
> I must admit that we (the Genode Labs team) do not assess ourselves as
> networking experts and, therefore, don't fancy to design and implement
> such a library. But as always nothing is set in stone and priorities
> may shift over time.
More information about the users